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Preface 


Preface 


Routers direct and control much of the data flowing across computer networks. This 
guide provides technical guidance intended to help network administrators and 
security officers improve the security of their networks. Using the information 
presented here, you can configure your routers to control access, resist attacks, shield 
other network components, and even protect the integrity and confidentiality of 
network traffic. 

This guide was developed in response to numerous questions and requests for 
assistance received by the NSA System and Network Attack Center (SNAC). The 
topics covered in the guide were selected on the basis of customer interest, and the 
SNAC’s background in securing networks. 

The goal for this guide is a simple one: improve the security provided by routers on 
US Department of Defense (DOD) operational networks. 

Who Should Use This Guide 

Network administrators and network security officers are the primary audience for 
this configuration guide, throughout the text the familiar pronoun “you” is used for 
guidance directed specifically to them. Most network administrators are responsible 
for managing the connections among parts of their networks, and between their 
network and various other networks. Network security officers are usually 
responsible for selecting and deploying the assurance measures applied to their 
networks. For this audience, this guide provides security goals and guidance, along 
with specific examples of configuring Cisco routers to meet those goals. 

Firewall administrators are another intended audience for this guide. Often, firewalls 
are employed in conjunction with filtering routers; the overall perimeter security of 
an enclave benefits when the configurations of the firewall and router are 
complementary. While this guide does not discuss general firewall topics in any 
depth, it does provide information that firewall administrators need to configure their 
routers to actively support their perimeter security policies. Section 5 includes 
information on using the firewall features of the Cisco Integrated Security facility. 

Information System Security Engineers (ISSEs) may also find this guide useful. 
Using it, an ISSE can gain greater familiarity with security services that routers can 
provide, and use that knowledge to incorporate routers more effectively into the 
secure network configurations that they design. 

Sections 4, 5, and 6 of this guide are designed for use with routers made by Cisco 
Systems, and mnning Cisco’s lOS software. The descriptions and examples in those 
sections were written with the assumption that the reader is familiar with basic Cisco 
router operations and command syntax. 
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Introduction 


1. Introduction 

1.1. The Roles of Routers in Modern Networks 

On a very small computer network, it is feasible to use simple broadcast or sequential 
mechanisms for moving data from point to point. An Ethernet local area network 
(LAN) is essentially a broadcast network. In larger, more complex computer 
networks, data must be directed specifically to the intended destination. Routers 
direct network data messages, or packets, based on internal addresses and tables of 
routes, or known destinations that serve certain addresses. Directing data between 
portions of a network is the primary purpose of a router. 

Most large computer networks use the TCP/IP protocol suite. See Section 2.3 for a 
quick review of TCP/IP and IP addressing. Figure 1-1, below, illustrates the primary 
function of a router in a small IP network. 



Figure 1-1 - A Simple Network with Two Routers 


If the user host (top left) needs to send a message to the file server (bottom right), it 
simply creates a packet with address 14.2.9.10, and sends the packet over LAN 1 to 
its gateway. Router 1. Consulting its internal routing table. Router 1 forwards the 
packet to Router 2. Consulting its own routing table. Router 2 sends the packet over 
LAN 3 to the File Server. In practice, the operation of any large network depends on 
the routing tables in all of its constituent routers. Without robust routing, most 
modem networks cannot function. Therefore, the security of routers and their 
configuration settings is vital to network operation. 


Version l.Og 


UNCLASSIFIED 


7 





























Router Security Configuration Guide 


UNCLASSIFIED 


In addition to directing packets, a router may be responsible for filtering traffic, 
allowing some data packets to pass and rejecting others. Filtering is a very important 
responsibility for routers; it allows them to protect computers and other network 
components from illegitimate or hostile traffic. For more information, consult 
Sections 3, 4, and 6. 
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Introduction 


1.2. Motivations for Providing Router Security Guidance 

Routers provide services that are essential to the correct, secure operation of the 
networks they serve. Compromise of a router can lead to various security problems 
on the network served by that router, or even other networks with which that router 
communicates. 

■ Compromise of a router’s routing tables can result in reduced 
performance, denial of network communication services, and exposure of 
sensitive data. 

■ Compromise of a router’s access control can result in exposure of network 
configuration details or denial of service, and can facilitate attacks against 
other network components. 

■ A poor router filtering configuration can reduce the overall security of an 
entire enclave, expose internal network components to scans and attacks, 
and make it easier for attackers to avoid detection. 

■ Proper use of router cryptographic security features can help protect 
sensitive data, ensure data integrity, and facilitate secure cooperation 
between independent enclaves. 

In general, well-configured secure routers can greatly improve the overall security 
posture of a network. Further, security policy enforced at a router is difficult for 
end-users to circumvent, thus avoiding one very serious potential source of security 
problems. 

There are substantial security resources available from router vendors. For example, 
Cisco offers extensive on-line documentation and printed books about the security 
features supported by their products. These books and papers are valuable, but they 
are not sufficient. Most vendor-supplied router security documents are focused on 
documenting all of the security features offered by the router, and do not always 
supply security rationale for selecting and applying those features. This guide 
attempts to provide security rationale and concrete security direction, with pertinent 
references at the end of each section identifying most useful of the vendor 
documentation. This guide also provides pointers to related vendor documents, 
standards, and available software. 
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1.3. Typographic and Diagrammatic Conventions Used in this Guide 

To help make this guide more practical, most of the sections include extensive 
instmctions and examples. The following typographic conventions are used as part 
of presenting the examples. 

■ Specific router and host commands are identified in the text using Courier 
bold typeface: “to list the current routing table, use the command show ip 
route.” Command arguments are shown in Courier italics: “syntax for a 
simple IP access list rule is access-list number permit host 

address.” 

■ Sequences of commands to be used in a configuration are shown 
separately from the text, using Courier typeface. The exclamation point 
begins a comment line, usually a remark about the line that follows it. 

! set the log host IP address and buffer size 
logging 14.2.9.6 
logging buffered 16000 

■ Transcripts of router sessions are shown separately from the text, using 
Courier typeface. Input in the transcript is distinguished from output, user 
input and comments are shown in Courier bold typeface. Elision of long 
output is denoted by two dots. In some cases, output that would be too 
wide to fit on the page is shown with some white space removed, to make 
it narrower. 


Central> enable 
Password: 


Central# 

! list 

interfaces in concise 

format 

Central# 

show ip 

interface brief 



Interface 

IP Address 

OK? 

Method 

Ethernet 

0/0 

14.2.15.250 

YES 

NVRAM 

Ethernet 

0/1 

14.2.9.250 

YES 

Manual 

Central# 

exit 





■ IP addresses will be shown in the text and in diagrams as A.B.C.D, or as 
A.B.C.D/N, where N is the number of set bits in the IP netmask. For 
example, 14.2.9.150/24 has a netmask of 255.255.255.0. (In general, this 
classless netmask notation will be used where a netmask is relevant. 
Otherwise, the bare address will be used.) 

■ Cisco lOS accepts the shortest unique, unambiguous abbreviation for any 
command or keyword. For commands that are typed very frequently, this 
guide uses the abbreviations commonly employed in the Cisco 
documentation and literature. For example, the interface name ethernet 
is commonly abbreviated “eth” and the command configure terminal 
is commonly abbreviated “config t”. 
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Introduction 


Discussions of network structure and security frequently depend on network 
diagrams. This guide uses the following set of icons in all of its diagrams. 



Server 


This icon represents a router. Each line 
connected to a router icon represents a 
network interface on that router. Each router 
is presumed to have an administrative console 
line connection, which is not shown. 


Computers on the network are represented 
with one of these two icons. 






Small LAN 

12.34.56.0/24 



A local-area network (LAN) segment, such as 
an Ethernet, is represented by a horizontal or 
vertical bus, with several connections. 



This icon represents a LAN or a wide-area 
network over which routers communicate. 
Such networks normally include other routers, 
and may include bridges, switches, link 
encrypters, and other network hardware. 
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1.4. Structural Overview 

The various parts of this guide are designed to be fairly independent; readers may 
want to skip directly to the sections most immediately useful to them. The list below 
provides a brief description of the major sections. Pertinent references are included 
at the end of each section. 

■ Section 2 reviews some background information about TCP/IP networking 
and network security, and describes some simple network security threats. 

■ Section 3 presents a security model for routers, and defines general goals 
and mechanisms for securing routers. This section also discusses some 
relationships between router security and overall network security. 

■ Section 4 details the methods and commands for apply ing security to 
Cisco routers, using recent versions of the Cisco lOS software. It is 
divided into six main parts: 

■ securing access to the router itself, 

■ securing router network services, 

■ controlling and filtering using a router, 

■ configuring routing protocols security, 

■ security management for routers, and 

■ network access control for routers. 

■ Section 5 describes advanced security services that some routers can 
provide, with a focus on Cisco routers’ capabilities. The two main topics 
of this section are IP security (IPSec) and using a Cisco router as a 
firewall. 

■ Section 6 presents testing and troubleshooting techniques for router 
security. It is essential for good security that any router security 
configuration undergoes testing, and this section presents both vendor- 
independent and Cisco-specific testing techniques. 

■ Section 7 previews some security topics that are not yet crucial for router 
configuration, but which may become important in the near future. 

■ Section 8 consists of four diverse appendices: 

■ tips for quickly improving the security of a router 

■ how to apply parts of this guide to LAN switches and other 
network hardware 

■ overview of the Cisco lOS software family and versions, and 

■ router security glossary. 

■ Section 9 provides a list of resources, collected from all the sections of the 
guide, including pointers to web sites and security tools. 
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Introduction 


How to Use This Guide 

Several different roles are involved in securing a network, and each may need some 
information about router security. The paragraphs below offer roadmaps for using 
this guide for several different network security roles. 

For network security planners and system security designers, the high-level view of 
router security is more important than the details of Cisco router commands. Read 
the sections listed below if your role is security planner or security designer role. 

■ Section 2 - for a review of TCP/IP, network, and router operational 
concepts 

■ Section 3 - for general router security principles 

■ Section 4.1 through 4.3 - for an idea of what Cisco routers can do for 
network security 

■ Section 5 - for information about Cisco router VPN and firewall 
capabilities 

■ Section 7 - for a preview of potential future issues 

For network administrators involved in the daily operation of a network with Cisco 
routers, the detailed instmctions for locking down a router are the most important 
part of this guide. Read the sections listed below if your role is network 
administrator. 


■ Section 2 - for a review, if necessary 

■ Section 3 - for the security principles behind the advice in Section 4 

■ Section 4 - for detailed instmctions on configuring Cisco routers 

■ Section 5.1, 5.2 - for instmctions on configuring IPSec on Cisco 
routers 

■ Section 8.1 - for prioritized advice for quickly securing a Cisco 
router 

■ Section 8.2 - for instmctions on applying this guide to LAN switches 

■ Section 8.3 - for information on Cisco lOS versions and upgrades 

■ Section 9 - for an overview of recommended references and tools 

For network security analysts or administrators trying to improve the security posture 
of a network as quickly as possible, this guide offers detailed advice and direction. 
Read the sections listed below if you goal is to quickly lock down a router. 

■ Section 8.1 - for quick tips that will greatly improve router security 

■ Section 4.1- for explicit directions on router access security 

■ Section 4.3 - for advice and guidance on setting up filtering 

■ Section 4.4 - for routing protocol security instmctions (unless the 
routers are using static routes exclusively) 
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Background and Review 


2. Background and Review 

This section reviews some background information about TCP/IP networking, router 
hardware architecture, router software architecture, and network security. In order to 
keep this section brief, it glosses over a lot of issues. To compensate for that 
briefness, the reference list at the end of the section includes a long list of other 
useful sources of background information. Readers with a good grasp of network and 
router fundamentals may want to skip this section, but since it is relatively brief, why 
not humor the author and read on. 

2.1. Review of TCP/IP Networking 

As mentioned in Section 1.1, on a small computer network, it is feasible to use 
simple broadcast or sequential (token) mechanisms for moving data from point to 
point. A local area network is composed of a relatively small number of hosts 
connected over a relatively small physical area. “Relatively small” is the important 
phrase here. To give some meaning to the term “relatively,” consider that a lOBaseT 
Ethernet (10 megabit per second using twisted pair cabling) has a usual maximum of 
1024 stations over a maximum cable distance of 2500 meters. For instance a typical 
office LAN, using 100BaseT Ethernet, might have 100 computers (and printers) 
attached to a switch or set of hubs. 

An Ethernet local area network (LAN) is essentially a (logical) bus based broadcast 
network; though the physical implementation may use hubs (with a physical star 
topology). As one would expect, broadcast LANs must deal with collisions; either by 
preventing them or detecting them and taking appropriate action. Token based LANs 
avoid collisions by only allowing one host at time to transmit (the host that currently 
has the token may transmit). 

Standards that relate to LANs are primarily the IEEE 802.x series. For instance, 

802.3 is the Media Access Control (MAC) standard for CSMA/CD (the Ethernet 
standard); while 802.5 is the MAC standard for Token Ring. Just above the MAC 
level is the Logical Link Control (802.2) standard and above that it the High Level 
Interface (802.1) standard. 

Within a LAN, addressing is done with a MAC address. Between LANs using 
TCP/IP addressing is done using IP addresses. If you are lost at this point, keep 
reading because much of this will be explained below. If you are still lost at the end 
of Section 2, then consider reading parts of some of the books and/or web pages 
listed at the end of the section. 

2.1.1. Purpose of a Router 

In larger, more complex computer networks, data must be directed more carefully. In 
almost all cases, large networks are actually composed of a collection of LANs that 
are interconnected or “internetworked”. This is where routers come in. Routers take 
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network data messages from a LAN and convert them into packets suitable for 
transmission beyond the LAN on a wide area network (WAN). The goal is almost 
always to get these packets to another LAN and ultimately to the correct host on that 
LAN. Part of the “conversion” process is to add a packet header. Other routers will 
generally only look at a packet’s header information, not at the contents or data in the 
packet. 

Routers also make decisions about where to send these packets, based on: the 
addresses contained within the packet headers and a table of routes maintained within 
the router. Updating these routing tables and forwarding data packets between 
portions of a network are one of the primary purposes of a router. Building packets 
and unwrapping packets are additional router functions performed by the first and 
last routers, respectively, that a message passes through. In addition to directing 
packets, a router may be responsible for filtering traffic, allowing some packets to 
pass through and rejecting others. Filtering can be a very important function of 
routers; it allows them to help protect computers and other network components. For 
more information about filtering, see Section 3 and Section 4. It is also possible that 
at the destination end a router may have to break large packets up to accommodate 
the size limits of the destination LAN. 

There is no reason that routers cannot be used to send messages between hosts (as 
shown in Figure 1-1) but more typically routers are used to connect LANs to each 
other or to connect a LAN to a WAN. 

Most large computer networks use the TCP/IP protocol suite. In some sense this is 
the lingua franca of the Internet. See Section 2.2 for a quick review of TCP/IP and 
IP addressing. 

2.1.2. Routing Tables 

As mentioned, one of tasks of a router is to maintain routing tables which are used to 
decide where a packet is to go and thus which interface it should be sent out. In the 
past these tables were built and updated by hand and this is referred to as static 
routing. In dynamic routing, the router learns about where various addresses are 
relative to itself and builds up routing tables based on this information. There are a 
number of schemes or routing protocols for routers to acquire and share routing table 
information. While a thorough treatment of the details is beyond the scope of this 
document, there is a brief discussion of routing protocols is in Section 4.4. 


16 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED 


Background and Review 


2.2. TCP/IP and the OSI Model 

2.2.1. Origin of TCP/IP 

The Transmission Control Protocol (TCP) and Internet Protocol (IP) comprise what 
is often seen written as TCP/IP. The Defense Advanced Research Projects Agency 
(DARPA) originated TCP/IP. Note that the word “Defense” has been deleted and 
added back over time. ARPA and DARPA are one and the same organization. The 
National Science Foundation (NSF) also contributed to foundation of the Internet by 
taking the DARPA technology and making it available to universities. 

As stated above, the Internet essentially mns on TCP/IP protocols. The definitive 
source for information on TCP/IP are the RFCs, or “Request for Comments” issued 
by the Internet Engineering Task Force as described in Section 2.7.3. Note that in 
addition to TCP/IP there are other protocols such as Novell’s IPX (Internetwork 
Packet exchange) that can be used with routers. Also, some routers can be used to 
“translate” between different protocols mnning on either side of themselves. 

2.2.2. The OSI Model 

After TCP/IP was well-established and other networking protocols, such as DECnet 
and Novell’s IPX were operational; the International Standardization Organization 
(ISO) developed the Open Systems Interconnection (OSI) seven layer reference 
model. These seven layers are described in almost every reference, so in the interest 
of space they are merely enumerated here. 

Layer 7: Application Layer - 

deals with services such as email and file transfer. 

Layer 6: Presentation Layer - 

deals with formatting, encryption, and compression of data. 

Layer 5: Session Layer - 

deals with setup and management of sessions between applications. 

Layer 4: Transport Layer 

deals with end to end error recovery and delivery of complete messages. 
Layer 3: Network Layer - 

deals with transmission of packets and establishing connections. 

Layer 2: Data Link Layer - 

deals with transmission of packets on one given physical link. 

Layer 1: Physical Layer - 

deals with transmission of a bit stream and definition of physical link. 

Since the development of TCP/IP preceded the ISO OSI seven layer model, the 
“mapping” of TCP and IP to the seven layer model is only an approximation. See 
Ligure 2-1, Network Layers and Standards, for a visual mapping of TCP/IP to the 
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OSI model. A collection of various compatible protocol layers is referred to as a 
stack. 


Layer 
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Logical Link Control 
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Physical 


TCP or UDP 
IP 

Data link 


Figure 2-1: Network Layers and Standards 

Routing occurs at layer three, the Network Layer. To fully understand routing it is 
useful to appreciate some of what goes on beneath it at the Data Link Layer, and 
some of this is discussed in the following sections. However, the Physical Layer is at 
a level of detail well below the concerns of this document. It is concerned with the 
transmission of an unstmctured bit stream over a physical link. This involves such 
details as signal voltage and duration; or optical signaling details for fiber. It also 
covers the mechanical aspects of connectors and cables. It may also cover some low 
level error control. 
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2.3. Review of IP Routing and IP Architectures 

If one is dealing only with a local area network (LAN), there is generally no need for 
routing, routers, TCP/IP, or IP addresses. Within a LAN everything will be handled 
by Media Access Control (MAC) addresses and by a LAN protocol such as Ethernet. 
At this level, most protocols are defined by Institute of Electrical and Electronic 
(IEEE) standards. Eor instance, IEEE 802.3 is the Ethernet (CSMA/CD) standard, 
802.4 is token bus, and 802.5 is token ring. Above the MAC standards, but still 
within the OSI Data Link Layer, is the IEEE 802.2 Logical Link Control standard. 
The IEEE 802.1 High Level Interface standard corresponds to part of the OSI 
Network Layer. If this seems confusing, do not worry about it; it’s not essential to an 
understanding of routers. 

What is important to keep in mind is that MAC addresses are used within a LAN. 
Each device on the LAN will have a something like a network interface card (NIC) 
which has a unique MAC address. Eor example, on an Ethernet LAN each device has 
an appropriate Ethernet card, say 100BaseT. The MAC address is appended to the 
front of the data before it is placed on the LAN. Each device on the LAN listens for 
packets with its address. 

Once a message is destined to leave one LAN bound for trip across a wide area 
network (WAN) to another LAN, it must use an IP address. While one can envision 
logical connections at various layers in a protocol stack, in reality bits can only move 
from one device to another at the Physical Layer. Thus, data begins at an application 
relative high up in a protocol stack and works its way down the stack to the physical 
layer. At this point it is transferred to another device and works its way up the 
protocol stack at that point. How far up the stack it goes depends on whether that 
device is the ultimate recipient of the data or merely an intermediate device. Eigure 
2-2 illustrates this process. Note that the data may pass through many intermediate 
devices on its way from the sending host to the ultimate recipient. 
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Figure 2-2: Moving Data through Protocol Stacks 

On the way down the stack, the packet will be wrapped by adding a header at each of 
the lower layers. The header is named for the protocol layer that adds it. Each new 
header is added in front of all higher layer headers. At the network layer, the IP 
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header added will contain the destination IP address (in addition to other 
information). At the data link layer, a new header that contains a MAC address will 
be added in front of this header. On the way up the stack, a header will be removed at 
each layer. Figure 2-3 should help you visualize how headers are added. 



Application 
Byte Stream 


TCP (or UDP) 
Packet 


IP 

Packet 


Ethernet Packet 
(or other media format message) 


Figure 2-3: Wrapping Lower Level Headers around Data 

2.3.1. MAC Addresses 

MAC addresses, sometimes referred to as Ethernet addresses are 48 bits long. They 
are assigned by the device (or card) manufacturer. Each address is unique and fixed 
to a particular piece of hardware. (On some newer devices it is possible to change 
them but normally this should not be done.) As stated previously, MAC addresses are 
used within a LAN by layer two (data link) protocols. 

Traditionally 24 bits uniquely identify the manufacturer and 24 bits act as a serial 
number to uniquely identify the unit. Some manufacturers have had more than one 
identification number (more than one block of serial numbers). Also, due to mergers 
and acquisitions the manufacturer identification is not as “clean” as it once was. Still, 
all devices have globally unique addresses unless their PROMs have been rewritten. 

2.3.2. IP Addresses 

Currently, IP addresses are 32 bits long. They are used by layer three devices such as 
routers. Unlike MAC addresses, IP addresses are hierarchical. 

There are four “classes” of IP addresses, referred to as: Class A, Class B, Class C, 
and Class D. In addition there a number of special addresses. Special addresses are 
used for such things as to broadcast to all hosts on a network or to specify a loopback 
packet which will never leave the host. The class determines how much of the 32 bit 
address is used to specify the network address and how much is used to specify the 
host within that network. The class is determined by the first one to four bits of the 
address. Any address beginning with a zero bit is a Class A address. Any address 
beginning with bits 10 is a Class B address. Any address beginning with bits 110 is 
Class C, and any beginning with bits 1110 is class D. 
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For any class, it is also possible to take the host portion of the address and further 
divide that range into two fields, which specify a subnet address and a host address 
respectively. This is done by specifying a parameter called a subnet mask. For a 
fuller discussion of subnetting see Albitton’s book [1] or one of the other references 
listed in Section 2.7.1. 

In addition to both source and destination addresses, there is a good bit of 
information in an IP header. It should be noted that the first 4 bits of an IP header 
contain a version number so new versions of the protocol can be implemented. 
Moreover the second 4 bits specify the length of the header. Thus it is quite feasible 
to introduce longer IP addresses. 
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2.4. Basic Router Functional Architecture 

2.4.1. Why Have a Special Purpose Router? 

What are some or the motivations for using a dedicated, purpose-built router rather 
than a general purpose machine with a “standard” operating system (OS)? What 
justifies this expense, and what justifies the bother of learning yet another system? 
The answer is partly that a special purpose router can have much higher performance 
than if router functionality were merely tacked onto a general purpose machine that 
might also be performing other functions. Also, one can potentially add more 
network connections to a machine designed for that purpose, because it can be 
designed to support more interface card slots. Thus, a special purpose device will 
probably be a lower cost solution for a given level of functionality. But there are also 
a number of security benefits to a special purpose router. 

For one thing, a specialized router operating system (like Cisco’s Internetwork 
Operating System or lOS) can be smaller, better understood, and more thoroughly 
tested than a general purpose OS. (Note that for brevity, the term lOS will be used in 
this document to refer the router’s operating system and associated software, but 
hardware other than Cisco would mn similar software.) This means that it is 
potentially inherently less vulnerable. Also, the mere fact that it is different means 
that an attacker has one more thing to learn, and that known vulnerabilities in other 
systems are of no help to the router attacker. Also, for security reasons it is desirable 
to have the access control list (ACL) up and mnning before enabling any interfaces 
or drivers. Finally, specialized routing software enables a fuller and more robust 
implementation of filtering. Filtering is useful as a “firewall” technique, and can also 
be used to partition networks and prohibit or restrict access to certain networks or 
servers. Using filtering, some routing protocols can prohibit the advertisement of 
routes to neighbors, thus helping protect certain parts of the network. 

2.4.2. Description of Typical Router Hardware 

A router is essentially just another computer. So, similar to any other computer, it has 
a central processor unit (CPU), various kinds of memory, and connections to other 
devices. Generally, a router does not have a hard disk, floppy drive, or CD-ROM 
drive. 

There are typically a number of types of memory in a router possibly including: 

RAM, NVRAM, Flash, and ROM (PROM, EEPROM). These are listed roughly in 
order of volatility. The mix of types and the amount of each type are determined on 
the basis of: volatility, ease of reprogramming, cost, access speed, and other factors. 
ROM is used to store a router’s bootstrap software. Non-volatile RAM (NVRAM) is 
used to store the startup configuration that the lOS reads when the router boots. Hash 
memory stores the lOS (or other router OS), and if there is enough flash it may store 
more than one version of lOS. Eigure 2-4 shows a simple representation of a notional 
router’s hardware structure. 


22 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED 


Background and Review 



Figure 2-4: A Notional Router’s Hardware 

Interfaces provide the physical connections from a router to networks. Interface types 
include Ethernet, fast Ethernet, token ring, EDDI, low-speed serial, fast serial, HSSI, 
ISDN BRI, etc. Each interface is named and numbered. Interface cards fit into slots 
in a router, and an external cable of the appropriate type is connected to the card. In 
addition to a number of interfaces, almost all routers have a console port providing an 
asynchronous serial connection (RS-232). Also, most routers have an auxiliary port, 
which is frequently used for connecting a modem for router management. These 
hardware ports should not be confused with the concept of software ports, such as the 
“well known” port associated with a protocol or service, e.g. port 23 is Telnet. 

2.4.3. Description of Typical Router Software 

Similar to any other computer, a router will run control program or operating system 
(OS). Each router vendor supplies their own router OS. In the case of Cisco routers, 
they mn Cisco’s Internetwork Operating System (lOS). It is the lOS that interprets 
the Access Control List (ACL) and other commands to the router. 

The startup or backup configuration is stored in NVRAM. It is executed when the 
router boots. As part of the boot process a copy of this configuration is loaded into 
RAM. Changes made to a mnning configuration are usually made only in RAM and 
generally take effect immediately. If changes to a configuration are written to the 
startup configuration, then they will also take effect on reboot. Changes made only to 
the mnning configuration will be lost upon reboot. 
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A running router will have a large number of processes executing. There are 
generally a number of router commands that give information on what processes are 
mnning and what resources, such as CPU time and memory, they are consuming. 

Each router should have a unique name to identify it, and each interface should have 
a unique network address associated with it. This is discussed in more detail later in 
this document. 
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2.5. Review of Router-Relevant Protocols and Layers 

The following sections are not inclusive of all protocols that might be of interest but 
are representative. For more details see Section 4.4, “Routing and Routing 
Protocols”. The protocols are grouped according the OSI layer to which they 
correspond. 

2.5.1. Physical Layer 1 

As previously discussed, the physical layer defined by IEEE or similar standards that 
define what are primarily hardware characteristics. 

2.5.2. Data Link Layer 2 

The IEEE and other standards that apply at this layer have also been discussed 
previously. 

2.5.3. Network Layer 3 

IP - the Internet Protocol (IP) provides a specification for packet formatting and an 
unreliable, connectionless, best effort delivery of those packets. 

ARP - Hosts use the Address Resolution Protocol (ARP) to acquire the MAC address 
of other hosts. 

2.5.4. Transport Layer 4 

TCP - the Transmission Control Protocol (TCP) is a connection-oriented, reliable 
protocol. Before transmitting data a connection must be established and after data 
transmission is complete the connection must be closed. 

UDP - the User Datagram Protocol (UDP) is a connectionless, best effort protocol 
with no guarantee of delivery or confirmation of delivery. It has lower overhead than 
TCP. When we speak of TCP/IP we are usually implicitly including UDP. 

ICMP - the Internet Control Message Protocol (ICMP) provides the mechanisms for 
hosts and routers to report network conditions and errors to other hosts and routers. 
(Eor example, the ping command relies on ICMP.) 

OSPE - Open Shortest Path Eirst is a relatively complex, fast-converging routing 
protocol. It is an interior gateway protocol that uses a link state routing algorithm and 
requires that a hierarchy of areas be designed. An area is a logical collection of 
routers and networks. 

RIP - Routing Information Protocol is a dynamic routing protocol that allows routers 
to share network information with each other. It is a distance vector protocol that 
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allows routers to only share information with nearest neighbors. It is used as an 
interior gateway protocol. 

2.5.5. Session Layer 5, Presentation Layer 6, and Application Layer 7 

These protocols are labeled (TCP) or (UDP) depending on which layer 5 protocol 
they are based upon. 

Telnet - (TCP) Enables terminal oriented processes to communicate. 

FTP - File Transfer Protocol (TCP) enables transfers of files between hosts. 

SMTP - Simple Mail Transport Protocol (TCP) is pretty much self-explanatory. 

DNS - Domain Name System (both TCP and UDP) performs naming resolution 
service by translating host names into IP addresses. 

TFTP - Trivial File Transfer Protocol (UDP) provides file transfers without any 
authentication or security. 

SNMP - Simple Network Management Protocol (UDP) enables a management 
station to trap certain information messages from network devices. 
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2.6. Quick “Review” of Attacks on Routers 

General threats include but are not limited to: unauthorized access, session hijacking, 
rerouting, masquerading, denial of service (DoS), eavesdropping, and information 
theft. In addition to threats to a router from the network, dial up access to a router 
exposes it to further threats. 

Attack techniques include: password guessing, routing protocol attacks, SNMP 
attacks, RIP attacks, IP fragmentation attacks - to bypass filtering, redirect (address) 
attacks, and circular redirect - for denial of service. 

Session replay attacks use a sequence of packets or application commands that can be 
recorded, possibly manipulated, and then replayed to cause an unauthorized action or 
gain access. 

Rerouting attacks can include manipulating router updates to cause traffic to flow to 
unauthorized destinations. 

Masquerade attacks occur when an attacker manipulates IP packets to falsify IP 
addresses. 

Session Hijacking may occur if an attacker can insert falsified IP packets after 
session establishment via IP spoofing, sequence number prediction and alteration, or 
other methods. 

Note that careful router configuration can help prevent a (compromised) site from 
being used as part of a distributed denial of service (DDoS) attack. DDoS attacks use 
a number of compromised sites to flood the target site with sufficient traffic to render 
it useless to legitimate users. 

An enumeration of steps to take to improve router security, and an explanation of the 
tradeoffs involved is the substance of later sections of this document. 
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3. Router Security Principles and Goals 

Routers can play a role in securing networks. This section describes general 
principles for protecting a router itself, protecting a network with a router, and 
managing a router securely. 

3.1. Protecting the Router Itself 

3.1.1. Physical Security 

There are a number of ways to provide physical security for a router. The room that 
contains the router should be free of electrostatic or magnetic interference. It should 
have controls for temperature and humidity. If deemed necessary for availability or 
criticality reasons, an unintermpted power supply (UPS) should be installed and 
spare components and parts kept on hand. To protect against some denial of service 
attacks the router should have the maximum amount of memory as possible. Also, 
the router should be placed in a locked room with access by only a small number of 
authorized personnel. Finally, physical devices (e.g., PC cards, modems) used to 
connect to the router require storage protection. 

3.1.2. Operating System 

The operating system for the router is a cmcial component. Decide what features the 
network needs, and use the feature list to select the version of the operating system. 
However, the very latest version of any operating system tends not to be the most 
reliable due to its limited exposure in a wide range of network environments. One 
should use the latest stable release of the operating system that meets the feature 
requirements. Section 3.3.2 discusses the management of updates to the operating 
system, and Sections 4 and 8 include information on Cisco’s lOS operating system. 

3.1.3. Configuration Hardening 

A router is similar to many computers in that it has many services enabled by default. 
Many of these services are unnecessary and may be used by an attacker for 
information gathering or for exploitation. All unnecessary services should be 
disabled in the router configuration. Section 3.3.2 discusses the management of 
updates to the router configuration. 
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3.2. Protecting the Network with the Router 

3.2.1. Roles in Perimeter Security and Security Policy 

A router provides a capability to 
help secure the perimeter of a 
protected network. It can do this 
by itself. The diagram at right 
shows a typical topology with the 
router being the component that 
connects the protected network to 
the Internet. 

A router can also be used as part of defense-in-depth approach as shown in the 
diagram below. It acts as the first line of defense and is known as a screening router. 
It contains a static route that passes all connections intended for the protected 
network to the firewall. The firewall provides additional access control over the 
content of the connections. It can also perform user authentication. This approach is 
recommended over using only a router because it offers more security. 





Figure 3-1: Typical One-router Internet Connection Configuration 



Another approach is to position one router at the connection between the local 
premises and the Internet, and then another router between the firewall and the 
protected network. This configuration offers two points at which policy can be 
enforced. It also offers an intermediate area, often called the de-militarized zone 
(DMZ) between the two routers. The DMZ is often used for servers that must be 
accessible from the Internet or other external network. 



Figure 3-2: Typical Two-router Internet Connection Configuration 


32 


UNCLASSIFIED 


Version l.Og 






















UNCLASSIFIED Router Security Principles and Goals 


3.2.2. Packet Filters for TCP/IP 

A packet filter for TCP/IP services provides control of the data transfer between 
networks based on addresses and protocols. Routers can apply filters in different 
ways. Some routers have filters that apply to network services in both inbound and 
outbound directions, while others have filters that apply only in one direction. (Many 
services are bi-directional. For example, a user on System A telnets to System B, and 
System B sends some type of response back to System A. So, some routers need two 
filters to handle bi-directional services.) Most routers can filter on one or more of the 
following: source IP address, source port, destination IP address, destination port, 
and protocol type. Some routers can even filter on any bit or any pattern of bits in the 
IP header. However, routers do not have the capability to filter on the content of 
services (e.g. FTP file name). 

Packet filters are especially important for routers that act as the gateway between 
trusted and untmsted networks. In that role, the router can enforce security policy, 
rejecting protocols and restricting ports according to the policies of the trusted 
network. Filters are also important for their ability to enforce addressing constraints. 
For example, in the Figure T1, the router should enforce the constraint that packets 
sent from the Firewall or protected network (right to left) must bear a source address 
within a particular range. This is sometimes called egress filtering. Similarly, the 
router should enforce the constraint that packets arriving from the Internet must bear 
a source address outside the range valid for the protected network. This is called 
ingress filtering. 

Two key characteristics of TCP/IP packet filters are length and ordering. A filter 
consists of one or more rules, with each mle either accepting or denying a certain set 
of packets. The number of mles in a filter determines its length. Generally, as the 
length grows the filter becomes more complex and more difficult to troubleshoot. 

The order of the rules in a packet filter is critical. When the router analyzes a packet 
against a filter the packet is compared to each filter rule in sequential order. If a 
match is found then the packet is either permitted or denied and the rest of the filter is 
ignored. If no match is found then the packet is denied due to the implicit deny rule 
at the end of the filter. You must carefully create filter mles in the proper order so 
that all packets are treated according to the intended security policy. One method of 
ordering involves placing those mles that will handle the bulk of the traffic as close 
to the beginning of the filter as possible. Consequently, the length and ordering of a 
packet filter mle set can affect the performance for passing packets through the 
router.* 


This discussion is applicable to the packet filtering facilities of Cisco routers and most other 
kinds of routers. Cisco filtering is discussed in detail in Section 4.3. If you have a router 
made by a company other than Cisco Systems, consult its documentation for details. 
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Applying Packet Filters: Permit Only Required Protocols and Services 

Carefully consider what network services will be allowed through the router 
(outbound and inbound) and to the router. If possible, use the following guideline for 
creating fdters: those services that are not explicitly permitted are prohibited 
Make a list of the services and protocols that must cross the router, and those that the 
router itself needs for its operation. Create a set of filtering rules that permit the 
traffic identified on the list, and prohibits all other traffic. 

In cases where only certain hosts or networks need access to particular services, add a 
filtering rule that permits that service but only the specific host addresses or address 
ranges. For example, the network firewall host might be the only address authorized 
to initiate web connections (TCP port 80) through the router. 


Applying Packet Filters: Reject Risky Protocols and Services 

Sometimes, it is not possible to follow the strict security guideline discussed above. 
In that case, fall back to prohibiting services that are commonly not needed, or are 
known to be popular vehicles for security compromise. The following two tables 
present common services to restrict because they can be used to gather information 
about the protected network or they have weaknesses that can be exploited against 
the protected network. The first table lists those services that should be completely 
blocked at the router. Unless you have a specific operational need to support them, 
the protocols listed in Table 3-1 should not be allowed across the router in either 
direction. 


Table 3-1: Services to Block Completely at the Router 


Port (Transport) 

Service 

1 (TCP & UDP) 

tcpmux 

7 (TCP & UDP) 

echo 

9 (TCP & UDP) 

discard 

11 (TCP) 

systat 

13 (TCP & UDP) 

daytime 

15 (TCP) 

netstat 

19 (TCP & UDP) 

chargen 

37 (TCP & UDP) 

time 

43 (TCP) 

whois 

67 (UDP) 

bootp 

69 (UDP) 

tftp 

93 (TCP) 

supdup 

111 (TCP & UDP) 

sunrpc 

135 (TCP & UDP) 

loc-srv 

137 (TCP & UDP) 

netbios-ns 

138 (TCP & UDP) 

netbios-dgm 

139 (TCP & UDP) 

netbios-ssn 
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Port (Transport) 

Service 

177 (UDP) 

xdmcp 

445 (TCP) 

netbios (ds) 

512 (TCP) 

rexec 

515 (TCP) 

Ipr 

517 (UDP) 

talk 

518 (UDP) 

ntalk 

540 (TCP) 

uucp 

2049 (UDP) 

nfs 

6000 - (TCP) 

X Window System 

6099 


6667 (TCP) 

ire 

12345 (TCP) 

NetBus 

12346 (TCP) 

NetBus 

31337 (TCP & UDP) 

Back Orifice 


Table 3-2 lists those services on the protected network or on the router itself that 
should not be accessible by external clients. 

Table 3-2: Some Services to Block at the Router from External Clients 


Port (Transport) 

Service 

79 (TCP) 

finger 

161 (TCP & UDP) 

snmp 

162 (TCP & UDP) 

snmp trap 

513 (TCP) 

rlogin 

513 (UDP) 

who 

514 (TCP) 

rsh, rep, rdist, rdump 

514 (UDP) 

syslog 

550 (TCP & UDP) 

new who 


Router filters should also be used to protect against IP address spoofing. In most 
cases, filtering rules should apply both ingress and egress filtering. 

Standard Ports and Protocols 

Some organizations maintain a list of standard ports and protocols that should be 
allowed or supported on their networks. Various organization in the DOD maintain 
such lists, and the Defense Information System Agency (DISA) is attempting to 
manage the creation of a standard list for the entire DOD. 

For networks that are subject to such lists, it is best to take the first approach, 
allowing only those ports and protocols mandated by the standard list, and rejecting 
all others. 
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3.3. Managing the Router 

3.3.1. Access Mechanisms for Administrators 

Determining access to the routers by administrators is an important issue. There are 
two types of access: local and remote. Local access usually involves a direct 
connection to a console port on the router with a dumb terminal or a laptop computer. 
Remote access typically involves allowing telnet or SNMP connections to the router 
from some computer on the same subnet or a different subnet. It is recommended to 
only allow local access because during remote access all telnet passwords or SNMP 
community strings are sent in the clear to the router. If an attacker can collect 
network traffic during remote access then he can capture passwords or community 
strings. However, there are some options if remote access is required. 

1. Establish a dedicated management network. The management network 
should include only identified administration hosts and a spare interface 
on each router. Figure 3-3 shows an example of this. 



2. Another method is to encrypt all traffic between the administrator’s 
computer and the router. In either case a packet filter can be configured 
to only allow the identified administration hosts access to the router. 
(Section 5.2 shows an example of doing this with a Cisco router and 
Windows 2000.) 

In addition to how administrators access the router, there may be a need to have more 
than one level of administrator, or more than one administrative role. Define clearly 
the capabilities of each level or role in the router security policy. For example, one 
role might be “network manager”, and administrators authorized to assume that role 
may be able to view and modify the configuration settings and interface parameters. 
Another role might be “operators”, administrators authorized to assume that role 
might be authorized only to clear connections and counters. In general, it is best to 
keep the number of fully privileged administrators to a minimum. 
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3.3.2. Updating the Router 

Periodically the router will require updates to be loaded for either the operating 
system or the configuration file. These updates are necessary for one or more of the 
following reasons: to fix known security vulnerabilities, to support new features that 
allow more advanced security policies or to improve performance. Before updating 
the administrator should complete some checks. Determine the memory 
requirements for the update, and if necessary install additional memory to the router. 
Set up and test file transfer capability between the administrator’s computer and the 
router. Schedule the required downtime (usually after regular business hours) for the 
router to perform the update. 

After obtaining an update from the router vendor, the administrator should follow 
procedures similar to the following. Shut down or disconnect the interfaces on the 
router. Back up the current operating system and the current configuration file to the 
administrator’s computer. Load the update for either the operating system or for the 
configuration file. Perform tests to confirm that the update works properly. If the 
tests are successful then restore or reconnect the interfaces on the router. If the tests 
are not successful then back out the update. 

3.3.3. Logging 

Logging on a router offers several benefits. It informs the administrator if the router 
is working properly or has been compromised. It can also show what types of attacks 
are being attempted against the router or the protected network. 

Configuring logging on the router should be done carefully. The administrator 
should have the router logs sent to a log host, which is a dedicated computer on the 
protected or tmsted network whose only job is to store logs. Harden the log host by 
removing all unnecessary services and accounts. Set the level of logging on the 
router to one that meets the needs of the security policy, and expect to modify the log 
settings as the network evolves. The logging level may need to be modified based on 
how much of the log information is useful to the administrator. Two areas that 
should be logged are (1) matches to filter rules that deny access, and (2) changes to 
the router configuration. 

Accurate timestamps are important to logging. All routers are capable of maintaining 
their own time-of-day, but this is usually not sufficient. Instead, direct the router to 
at least two different reliable time servers to ensure accuracy and availability of time 
information. Also, direct the logging host to the reliable time servers. Include a 
timestamp in each log message. This will allow the administrator to trace network 
attacks more credibly. Finally, consider also sending the logs to a dedicated printer 
to deal with worst case scenarios, e.g., failure of the log host. 
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3.4. Security Policy for Routers 

Routers are an important part of a network, and their security is a vital part of the 
overall security for the networks they serve. What does it mean for a router to be 
secure? One simple way to define the security of a router is this: do the operation, 
configuration, and management of the router satisfy a good security policy? 

3.4.1. A Conceptual Basis for Router Security Policy 

Figure 3, below, shows a layered view of the security of a router. The security of 
each layer depends on the security of the layers inside it. 


Router Security 
Layers 








f ■> 

Physical Integrity 
of the Router ^ 


Core Static Configuration 


of the Router 

J 


Dynamic Configuration 
and Status of the Router 




Network Traffic through the Router 


Corresponding Access 

• Physical access 

• Electrical access 


• Administrative access 

• Software updates 

• Routing protocols 


• Access to the network that 
the router serves 


Figure 3-4: Layered View of Router Security 

The innermost zone is the physical security of the router. Any router can be 
compromised by an attacker with full physical access; therefore, physical access must 
be limited to provide a solid foundation for the overall security of the router. Most 
routers offer one or more direct connections, usually called ‘Console’ or ‘Control’ 
ports; these ports usually provide special mechanisms for controlling the router. 
Router security policy should define rules for where and how these ports may be 
used. 


The next innermost zone of the diagram is the stored software and configuration state 
of the router itself. If an attacker can compromise either of these, particularly the 
stored configuration, then they will also gain control of the outer two layers. Some 
important aspects of the stored configuration are the interface addresses, the user 
names and passwords, and the access controls for direct access to the router’s 
command interface. Security policy usually includes strict rules about access to this 
layer, in terms of both administrative roles and network mechanisms. 

The next outermost zone of the diagram is the dynamic configuration of the router. 
The route tables themselves are the most obvious part of this. Other pieces of 
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dynamic information, such as interface status, ARP tables, and audit logs, are also 
very important. If an attacker can compromise the dynamic configuration of a 
router, they can compromise the outermost layer as well. Security policy for a router 
should include rules about access to this layer, although it is sometimes overlooked. 

The outer zone of the diagram represents the intra-network and inter-network traffic 
that the router manages. The overall network security policy may include rules 
about this, identifying permitted protocols and services, access mechanisms, and 
administrative roles. The high-level requirements of the network security policy 
must be reflected in the configuration of the router, and probably in the router 
security policy. 

3.4.2. Router Security Policy and Overall Network Security Policy 

Typically, the network that a router serves will have a security policy, defining roles, 
permissions, rules of conduct, and responsibilities. The policy for a router must fit 
into the overall framework. The role s defined in the router security policy will 
usually be a subset of those in the network policy. The rules of conduct for 
administering the router should clarify the application of the network mles to the 
router. 

For example, a network security policy might define three roles: administrator, 
operator, and user. The router security policy might include only two: administrator 
and operator. Each of the roles would be granted privileges in the router policy that 
permit them to fulfill their responsibilitie s as outlined in the network policy. The 
operator, for example, might be held responsible by the network security policy for 
periodic review of the audit logs. The router security policy might grant the operator 
login privileges to the router so that they can access the router logs. 

In other regards, the router policy will involve far more detail than the network 
policy. In some cases, the router enforces network policy, and the router policy must 
reflect this. 

For example, the network security policy might forbid administration of the router 
from anywhere but the local LAN. The router policy might specify the particular 
mles to be enforced by the router to prevent remote administration. 

3.4.3. Creating a Security Policy for a Router 

There are several important tips to remember when creating the security policy for a 
router: 


■ Specify security objectives, not particular commands or mechanisms - 
When the policy specifies the security effect to achieve, rather than a 
particular command or mechanism, the policy is more portable across 
router software versions and between different kinds of routers. 
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■ Specify policy for all the zones identified in the figure above - 

Begin with physical security, and work outwards to security for the static 
configuration, the dynamic configuration, and for traffic flow. 

■ Services and protocols that are not explicitly permitted should be denied - 
When representing the network policy in the router policy, concentrate on 
services and protocols that have been identified as explicitly needed for 
network operation; explicitly permit those, and deny everything else. 

In some cases, it may not be practical to identify and list all the services and 
protocols that the router will explicitly permit. A backbone router that must route 
traffic to many other networks cannot always enforce highly tailored policies on the 
traffic flowing through it, due to performance concerns or differences in the security 
policies of the different networks served. In these kinds of cases, the policy should 
clearly state any limitations or restrictions that can be enforced. When drafting a 
policy, keep most of the directives and objectives high-level; avoid specifying the 
particular mechanisms in the policy. 

A security policy must be a living document. Make it part of the security practices of 
the network to regularly review the network security policy and the router security 
policy. Update the router policy to reflect changes in the network policy, or 
whenever the security objectives for the router change. It may be necessary to revise 
the router security policy whenever there is a major change in the network 
architecture or organizational structure of network administration. In particular, 
examine the router security policy and revise it as needed whenever any of the 
following events occur. 

■ New connections made between the local network and outside networks 

■ Major changes to administrative practices, procedures, or staff 

■ Major changes to the overall network security policy 

■ Deployment of substantial new capabilities (e.g. a new VPN) or new 
network components (e.g. a new firewall) 

■ Detection of an attack or serious compromise 

When the router security policy undergoes a revision, notify all individuals 
authorized to administer the router and all individuals authorized for physical access 
to it. Maintaining policy awareness is crucial for policy compliance. 

3.4.4. Router Security Policy Checklist 

The checklist below is designed as an aid for creating router security policy. After 
drafting a policy, step down the list and check that each item is addressed in your 
policy. 
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Physical Security 

□ Designates who is authorized to install, de-install, and move the router. 

□ Designates who is authorized to perform hardware maintenance and to change 

the physical configuration of the router. 

□ Designates who is authorized to make physical connections to the router. 

□ Defines controls on placement and use of console and other direct access port 

connections. 

□ Defines recovery procedures for the event of physical damage to the router, or 

evidence of tampering with the router. 

Static Configuration Security 

□ Designates who is authorized to log in directly to the router via the console or 

other direct access port connections. 

□ Designates who is authorized to assume administrative privileges on the 

router. 

□ Defines procedures and practices for making changes to the router static 

configuration (e.g. log book, change recording, review procedures) 

□ Defines the password policy for user/login passwords, and for administrative 

or privilege passwords. 

□ Designates who is authorized to log in to the router remotely. 

□ Designates protocols, procedures, and networks permitted for logging in to 

the router remotely. 

□ Defines the recovery procedures, or identifies individual responsible for 

recovery, in the case of compromise of the router’s static configuration. 

□ Defines the audit log policy for the router, including outlining log 

management practices and procedures. 

□ Designates procedures and limits on use of automated remote management 

and monitoring facilities (e.g. SNMP) 

□ Outlines response procedures or guidelines for detection of an attack against 

the router. 

□ Defines the key management policy for long-term cryptographic keys (if any). 

Dynamic Configuration Security 

□ Identifies the dynamic configuration services permitted on the router, and the 

networks permitted to access those services. 
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□ Identifies the routing protocols to be used, and the security features to be 

employed on each. 

□ Designates mechanisms and policies for setting or automating maintenance of 

the router’s clock (e.g. manual setting, NTP) 

□ Identifies key agreement and cryptographic algorithms authorized for use in 

establishing VPN tunnels with other networks (if any). 

Network Service Security 

□ Enumerates protocols, ports, and services to be permitted or filtered by the 

router, OR identifies procedures and authorities for authorizing them. 

□ Defines response procedures, authorities, and objectives for the event of 

detection of attack against the network. 
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This is the main site for looking up Internet RFCs. The retrieval service 
supports a variety of keyword searches, as well as straight by-number 
lookup. 

[7] “Network Security Policy: Best Practices White Paper”, Cisco White Paper, 
Cisco Systems, 2000. 

available at: http : //www .cisco . com/warp/public/12 6/ secpol. htm 
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4. Implementing Security on Cisco 
Routers 


The diagram below shows a simple network configuration. The structures and 
addresses illustrated here are used for all of the examples in Sections 4, 5, and 6. 



14 . 2 . 10 . 6/24 14 . 2 . 10 . 2/24 

Figure 4-1: Network Diagram for Examples 

Figure 4-1 is simply a vehicle for presenting security guidance about routers, it is not 
a design for a secure network. However, this architecture accurately reflects the 
kinds of networks found in many organizations. 
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4.1. Router Access Security 

This section discusses the various mechanisms used to protect the router itself. These 
include physical access, user account protection, software protection, remote 
administration concerns, and configuration issues. When thinking about the security 
of your network it is important to consider these issues for all your systems, where 
applicable, as well as to the routers. 

4.1.1. Physical Security 

Once an individual has physical access to a piece of networking equipment there is 
no way to stop them from modifying the system. This problem is not only confined 
to network devices but is also true of computers and any other electrical or 
mechanical device. It is always a matter of time and effort. There are things that can 
be done to make this more difficult, but a knowledgeable attacker with access can 
never be completely defeated, only slowed down. One of the best additions to the 
security features of a computer network is to limit access. Network infrastmcture 
components, like routers, are especially important because they are often used to 
protect segments of the network and can also be used for launching attacks against 
other network segments. 

Network equipment, especially routers and switches, should be located in a limited 
access area. If possible, this area should only be accessible by personnel with 
administrative responsibilities for the router. This area should be under some sort of 
supervision 24 hours a day and 7 days a week. This can be accomplished through the 
use of guards, system personnel, or electronic monitoring. In practice, physical 
security mechanisms and policies must not make access too difficult for authorized 
personnel, or they may find ways to circumvent the physical security precautions. 

If remote administration is used to configure and control routers, then consider ways 
of protecting the machines used for remote administration, and the networks they use 
to communicate with the router. Use access lists to limit remote administration 
access to hosts that enjoy reasonable physical security. 

To illustrate one reason why physical security is critical to overall router security, 
consider the password recovery procedure for Cisco routers. This procedure is able 
to acquire full privileged (enable) access to a Cisco router without using a password. 
The details of the procedure varies between router models, but always includes the 
following basic steps. An administrator (or an attacker) can simply connect a 
terminal or computer to the console port and 

“Step 1 Configure the router to boot up without reading the 

configuration memory (NVRAM). This is sometimes called 
the test system mode. 

Step 2 Reboot the system. 

Step 3 Access enable mode (which can be done without a password 
if you are in test system mode). 
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Step 4 View or change the password, or erase the configuration. 

Step 5 Reconfigure the router to boot up and read the NVRAM as it 
normally does. 

Step 6 Reboot the system.”' 

Anyone with experience or training using Cisco routers can parley physical access 
into full privileged administrative on a Cisco router; the procedure takes only a 
couple of minutes. (Note: Step 5 is very important; if you need to use the password 
recovery procedure for any reason, do not neglect to restore the system boot settings 
after regaining access to the router. Failure to do so will usually result in the router 
coming up in an insecure state on subsequent reboots.) 

A second reason for controlling physical access to the router involves flash memory 
cards. Many Cisco router models offer PCMCIA slots that can hold additional flash 
memory. Routers equipped with these kinds of slots will give preference to memory 
installed in a slot over memory installed in the chassis. An attacker with physical 
access to a router on your network can install a flash memory card, or replace an old 
one. They could then boot the router with their flash, thus causing the router to mn 
their lOS version and configuration. If done carefully and well, this kind of attack 
can be very difficult to detect. The best defense against it is good physical security. 

An operational security concern closely related to physical security is physical 
operating environment. Like most networking equipment, routers are sensitive to 
extreme temperature and humidity. If a router is not located in an environmentally 
friendly area then it may operate in unexpected ways and degrade its security. This is 
also a personnel safety issue. A room where routers are located should be free of 
electrostatic and magnetic interference. The area should also be controlled for 
temperature and humidity. If at all possible, all routers should be placed on an 
Unintermptible Power Supply (UPS), because a short power outage can leave some 
network equipment in undetermined states. 

The console (con) and auxiliary (aux) ports on Cisco routers are used for serial 
connections to the router. Most Cisco routers have both a console and an auxiliary 
port, some of the smallest models have only a console port. The primary difference 
between the two ports is that the password recovery mechanism can be used on the 
console port only. In many cases, the auxiliary port is unused. Some administrators 
connect a modem to the auxiliary port to facilitate remote administration via dial-up. 
Permitting direct dial in to any vital piece of network infrastmcture is potentially 
very risky, and should be set up only when timely access by other means is not 
feasible. In general, the auxiliary port should be disabled (see Section 4.1.3). 


' Cisco lOS Release 12.0 Security Configuration Guide, “Configuring Passwords and 
Privileges”, “Password Recovery Process” Cisco Systems, 1999. 
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4.1.2. Router Software Versions 

Cisco issues new lOS versions and upgrades fairly frequently; making it an 
administrative nightmare to keep all the routers on a large network up to date. Newer 
versions of lOS fix bugs and vulnerabilities that existed in the older versions, and add 
new security features. Keep your lOS as up to date as is practical. A second problem 
is that the early versions of new lOS releases can be less robust than more mature, 
later versions (i.e. 12.0.1 was an early version of lOS Release 12, while 12.0.9 was a 
mature version of Release 12). A good approach to this problem is to maintain 
operational routers with recent, but not cutting-edge, Cisco lOS releases. This will 
allow others to find the bugs in the newer versions (and get them fixed). The 
recommended minimum lOS release is lOS 11.3. The recommended newest release 
would be the most recent “GD” version that is at least a month old (at the time of this 
writing, 12.0.12). To check your lOS version, log in and enter the command show 
version. For more details on lOS upgrades, see Sections 4.5 and 8.3. 

4.1.3. Router Configuration and Commands (lOS) 

After connecting to a router and initially logging in, the system is in user mode also 
known as EXEC mode. EXEC mode gives limited access to the command set of the 
router. Access to all the router commands, including the ability to change the 
configuration, is reserved for the privileged EXEC mode. Typing the enable 
command at an EXEC mode prompt will give access to the privileged EXEC mode. 
Privileged EXEC mode is sometimes called ‘enable mode’. 

There are several configuration modes on a Cisco router. To enter the global 
configuration mode (config) type the command configure terminal , commonly 
abbreviated “config t”. In the global configuration mode a wide variety of overall 
router features and settings can be changed: banners, authentication systems, access 
lists, logging, routing protocols, and much more. There are sub-modes which are 
used to configure specific settings for interfaces, lines, routing protocols, etc. The list 
below describes some of the sub-modes. 

■ interface (config-if) is used to configure aspects of a particular interface 
like EastEthemetO, Ethernet 0/1, or Vlan2. 

■ line (config-line) is used to set up the console port, auxiliary port and 
virtual terminal lines. 

■ access-list: There are two types of IP named access lists, extended 
(config-ext-n) and standard (config-std-n), which can be used instead of 
numbered lists. Access-list mode is used for building named access lists. 

■ route (config-route) is where specific parameters can be set and modified 
for a selected routing protocol. 

In addition to the standard authentication, authorization, and logging router functions, 
Cisco lOS 11.1 and later offer a comprehensive model for authentication, 
authorization, and accounting (AAA), the so-called ‘new model’. See Section 4.1.6 
for a brief description and Section 4.6 for more details. 
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4.1.4. Logins, Privileges, Passwords, and Accounts 
Logins 

A login banner, which includes a legal notice, should be set up on each operational 
router.* Network architecture information and router configuration details should not 
be included in the banner message. Router model and location information should be 
included only if necessary. Be especially careful not to provide information in the 
banner message that should not be shared with the general public, or information that 
is not visible from unprivileged EXEC mode. To set the router's banner use the 
command: banner motd delimiter message delimiter 

The console (con) port is the default location for performing router management and 
configuration. It is okay to leave a connection to the console port attached all the 
time, but that terminal (or computer) should be standalone, and protected from casual 
access. The connection to the console port should not be left logged in. Configure 
the console line to time out, so that if an administrator forgets to log out, the router 
will log him or her out automatically. Each authorized user should login using their 
own account (see Accounts sub-section, below). The example below shows how to 
set up the console line to enforce user login and a five-minute timeout. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# line con 0 

Central(config-line)# transport input none 

Central(config-line)# login local 

Central(config-line)# exec-timeout 5 0 

Central(config-line)# end 

Central# 

Note that, to enforce console login, as shown above, you must create at least one user 
account, otherwise you will be locked out of the console. If you do not already have 
users accounts set up, then create at least one before setting the console to use login 
local. The syntax for creating a local user is username name privilege level 
password string. The example below shows how to create an account with a 
password. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# username brian privilege 1 password g00d+pa55w0rd 

Central(config)# end 
Central# 


A legal notice usually includes a ‘no trespassing’ warning, and a statement that all use of the 
router must be authorized by the owning organization. A proper legal notice protects the 
ability of the owning organization to pursue legal remedies against an attacker. Consult your 
organization’s legal staff or general counsel for suitable language to use in your legal notice. 
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The auxiliary port, if at all possible, should be disabled. Router Central, in the 
sample network diagram (Figure 4-1), has no need for the aux port. The example 
below shows how to disable login on the auxiliary port (login to enable mode first): 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# line aux 0 

Central(config-line)# transport input none 

Central(config-line)# login local 

Central(config-line)# exec-timeout 0 1 

Central(config-line)# no exec 

Central(config-line)# end 

Central# 

Section 4.1.5 discusses configuration of the auxiliary port if it is required for a 
modem. If the auxiliary port is required for a second local serial connection then 
configure it as shown below. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# line aux 0 

Central(config-line)# exec-timeout 5 0 

Central(config-line)# login local 

Central(config-line)# transport input none 

Central(config-line)# exec 

Central(config-line)# end 

Central# 

The primary mechanism for remote administration of Cisco routers is logging in via 
Telnet; these connections are called virtual terminal lines. Login on the virtual 
terminal lines should be disabled if remote administration is not absolutely necessary. 
Remote administration is inherently dangerous because anyone with a network 
sniffer on the right LAN segment can acquire the router passwords and would than be 
able to take control of the router. To disable network virtual terminal connections to 
the router, create an access list and apply it to the virtual terminal lines as shown in 
the example below. [Note: perform these commands only when connected to the aux 
or console port, do not perform them while logged into the router via Telnet.] 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# no access-list 90 

South(config)# access-list 90 deny any log 

South(config)# line vty 0 4 

South(config-line)# access-class 90 in 

South(config-line)# transport input none 

South(config-line)# login local 

South(config-line)# exec-timeout 0 1 

South(config-line)# no exec 

South(config-line)# end 

South# 

If remote administration is necessary, see Section 4.1.5 for details on configuring 
remote administration. 
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Privileges 

Cisco lOS provides for 16 different privilege levels ranging from 0 to 15. The Cisco 
lOS comes with 2 predefined user levels. User EXEC mode runs at privilege level 1 
and “enabled” mode (privileged EXEC mode) runs at level 15. Every lOS command 
is pre-assigned to either level 1 or level 15. If the router is configured with aaa 
new-model then AAA can be used for user authorization (see Section 4.6 for more 
details). 

By default Cisco provides EXEC (level 1) with a few commands which may make 
more sense being at a higher privilege level. The next example shows how to move 
the commands to the privileged mode, which in most configurations should be 
protected better. 


Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

15 

Central 

(config)# 

privilege 

exec 

level 

1 


connect 

telnet 

rlogin 

show ip access-lists 
show access-lists 
show logging 
show ip 


The last line is required to move the show command back down to level 1. 


One possible scenario, would be if a site wanted to set up more than the two levels of 
administration on their routers. This could be done by assigning a password to an 
intermediate level, like 5 or 10, and then assigning the extra commands to that 
privilege level. This is beyond the scope of this document. But, if an attempt was 
made to do something like this there are a few things to be very careful about. Eirst, 
do not use the username command to set up accounts above level 1, use the enable 
secret command to set a level password instead (see next sub-section). Second, be 
very careful about moving too much access down from level 15, this could cause 
unexpected security holes in the system. Third, be very careful about moving any 
part of the configure command down, once a user has write access they could 
leverage this to acquire greater access. 


Passwords 

There are two password protection schemes in Cisco lOS. Type 7 uses the Cisco- 
defined encryption algorithm which is known to the commercial security community 
to be weak. Type 5 uses an MD5 hash which is much stronger. Cisco recommends 
that Type 5 encryption be used instead of Type 7 where possible (see Configuring 
Passwords and Privileges in the Cisco lOS Security Configuration Guide). 

Type 7 encryption is used by the enable password, username, and line 
password commands. 
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■ To protect the privileged EXEC level as much as possible, do not use the 
enable password command, only use the enable secret command. 
Even if the enable secret is set do not set the enable password, it 
will not be used and may give away a system password. 

South# config t 

Enter configuration commands, one per line. End with 
CNTL/Z . 

South (config) # enable secret 2-inAny-rOUtEs 
South(config)# no enable password 

South(config)# end 
South# 


■ Because it is not possible to use Type 5 encryption on the default EXEC 
login or the username command, no user account should be created above 
privilege level 1. But user accounts should be created for auditing 
purposes (see Accounts, below). So the username command should be 
used to create individual user accounts at the EXEC level and then the 
higher privilege levels should be protected with enable secret 
passwords. Then users with a need to work at higher levels would be 
given the higher privilege level password. 

■ If the login command is used to protect a line then the line password 
command is the only way to set a password on a line. But if the login 
local command is used to protect a line then the specified user 
name/password pair is used. Eor access and logging reasons the login 
local method should be used. 

In addition to the above password access mechanisms, AAA mechanisms may be 
used to authenticate, authorize, and audit users (see Section 4.6 for details). 

Good security practice dictates some other rules for passwords. Some of the more 
important rules are provided in the following list (assuming login local is used on 
all the lines): 

■ The privileged EXEC secret password should not match any other user 
password or any other enable secret password. 

■ Enable service password-encryption; this will keep passersby from 
reading your passwords when they are displayed on your screen. 

■ Be aware that there are some secret values that service password- 
encryption does not protect. Never set any of these secret values to the 
same string as any other password. 

■ SNMP community strings - for more information about SNMP 
security see Section 4.5.3. 

■ RADIUS keys 

■ TACACS+keys 


52 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED Implementing Security on Cisco Routers 


■ Avoid dictionary words, names, or dates. 

■ Always include at least one of each of the following: lowercase letters, 
uppercase letters, digits, and special characters. 

■ Make all passwords at least eight characters long. 

■ Avoid more than 4 digits or same-case letters in a row. 

See [4] for more detailed guidance on selecting good passwords. Note: enable 
secret and username passwords may be up to 25 characters long including 
spaces. 


Accounts 


First, give each administrator their own login user name for the router. When an 
administrator logs in with a user name and changes the configuration, the log 
message that is generated will include the name of the login account which was used. 
The login accounts created with the username command should be assigned 
privilege level 1 (see Passwords, above). In addition, do not create any user accounts 
without passwords! When an administrator no longer needs access to the router, 
remove their account. The example below shows how to create accounts for users 
named ‘rsmith’ and ‘bjones’, and remove the user named ‘brian’. 


Central# config 
Enter configurat 
Central(config)# 
Central(config)# 
Central(config)# 
Central(config)# 
Central(config)# 
Central(config)# 
Central# 


t 

ion commands, one per line. End with CNTL/Z. 

username rsmith password 3d-zirc0nia 
username rsmith privilege 1 
username bjones password 2B-or-3B 
username bjones privilege 1 
no username brian 
end 


Only allow accounts that are required on the router and minimize the number of users 
with access to configuration mode on the router. See Section 4.6, which describes 
AAA, for a preferred user account mechanism. 

4.1.5. Remote Access 

This document will discuss five connection schemes which can be used for router 
administration. 

1. No Remote - administration is performed on the console only. 

2. Remote Internal only with AAA - administration can be performed on 
the router from a trusted internal network only, and AAA is used for 
access control. 
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3. Remote Internal only - administration can be performed on the router 
from the internal network only. 

4. Remote External with AAA - administration can be performed with both 
internal and external connections and uses AAA for access control. 

5. Remote External - administration can be performed with both internal 
and external connections. 

As discussed in Section 4.1.3, remote administration is inherently dangerous. When 
you use remote administration, anyone with a network sniffer and access to the right 
LAN segment can acquire the router account and password information. This is why 
remote administration security issues center around protecting the paths which the 
session will use to access the router. The five regimes listed above are listed in the 
order that best protects the router and allows for accounting of router activities. 
Section 4.6 will discuss remote access with AAA. This section will discuss remote 
internal only access without AAA. Section 4.6 will also discuss Remote External 
connections using AAA and an IPSec Tunnel (see Section 5.2). Remote external 
access should not be used either with or without AAA unless the traffic is protected 
since the username password will travel the network in clear text form otherwise. 

So the security of remote administration can be enhanced by using a security 
protocol. Cisco is beginning to add support for the Secure Shell (SSH) protocol to 
lOS; once it is available, SSH will also be a good choice for securing administrative 
connections. 

The Auxiliary Port 

As discussed in Section 4.1.3 the aux port should be disabled. Only if absolutely 
required should a modem be connected to the aux port as a backup or remote access 
method to the router. Attackers using simple war-dialing software will eventually 
find the modem, so it is necessary to apply access controls to the aux port. As 
discussed earlier, all connections to the router should require authentication (using 
individual user accounts) for access. This can be accomplished by using login 
local (see next sub-section for example) or AAA (see section 4.6). Eor better 
security, lOS callback features should be used. A detailed discussion on setting up 
modems is beyond the scope of this document. See the Cisco lOS Release 12.0 Dial 
Solutions Configuration Guide for a complete discussion of connecting modems and 
configuring lOS callback features. 

Network Access 

Remote network connections use the vtys to connect to the router. To configure the 
vty’s for remote access do the following: 

Central(config) # access-list 99 permit 14.2.9.1 log 
Central(config) # access-list 99 permit 14.2.6.6 log 
Central(config) # access-list 99 deny any log 
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Central(config)# line 
Central(config-line)# 
Central(config-line) # 
Central(config-line) # 
Central(config-line) # 
Central(config-line)# 
Central(config-line) # 
Central# 


vty 0 4 

access-class 99 in 
exec-timeout 5 0 
login local 

transport input telnet 

exec 

end 


The access-list limits which hosts may connect to the router through the vty ports. 
Additionally, the IP addresses which are allowed to connect must be on an internal 
interface, see Figure 4-1 for example. For more details on access-lists see Section 
4.3. The login local command requires a username and password be used for 
access to the router, which is different for AAA mechanisms. Finally, the 
transport input telnet command restricts the management interface to telnet 
only. This is important because the other supported protocols, like rlogin and web, 
are less secure and should be avoided. 


4.1.6. Authentication, Authorization, and Accounting (AAA) 

This is Cisco’s new access control facility for controlling access, privileges, and 
logging of user activities on a router. Authentication is the mechanism for 
identifying users before allowing access to a network component. Authorization is 
the method used to describe what a user has the right to do once he has authenticated 
to the router. Accounting is the component that allows for logging and tracking of 
user and traffic activities on the router which can be used later for resource tracking 
or trouble shooting. Section 4.6 contains details on configuring AAA in an example 
network. 


4.1.7. Logistics for Configuration Loading and Maintenance 

There are two basic approaches for configuration loading and maintenance: online 
editing and offline editing. They each have advantages and disadvantages. Online 
editing provides for syntax checking but provides limited editing capability and no 
comments. Offline editing provides the ability to add comments, allows for the use 
of better editors, and guarantees all settings will be visible, but provides no syntax 
checking. With the online editing, the show run command will only show those 
configuration settings which are different from the lOS defaults. Cisco configuration 
save utilities will also not save default values. Because each Cisco lOS release 
changes the default values for some of the commands, tracking the configuration can 
become very difficult. But the offline method will leave passwords in the clear. The 
recommended approach is a hybrid of the two, described below. 

It is also important to keep the mnning configuration and the startup configuration 
synchronized, so that if there is a power failure or some other problem the router will 
restart with the correct configuration. If there is a need for old or alternative 
configurations they should be stored offline. In this situation it is only necessary to 
manage the startup configuration since the mnning configuration is identical. Wlien 
saving and loading configurations, always use the startup configuration to avoid 
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problems. Also, maintain the configuration offline by writing it offline (see above). 
Only save off the mnning configuration for an emergency, because the saving will 
not include default values and on an lOS upgrade there will be unexpected 
configuration problems. 

When managing configuration files offline there are several security issues. First, the 
system where the configuration files are stored should use the local operating 
system’s security mechanisms for restricting access to the files. Only authorized 
router administrators should be given access to the files. Second, if you set 
passwords in an offline configuration file, then they will be stored in the clear and 
transferred in the clear. Instead, it is best to type the passwords while on-line (using 
the console) and then copy the encrypted strings to the offline configuration. This is 
especially tme for the enable secret password. Third, with the configuration 
files offline the files must be transferred to the router in the relatively secure method. 
The possible methods for transferring files to a router have increased with newer lOS 
releases. The primary mechanisms available are the console terminal, telnet, tftp, 
rep, and ftp (available for lOS 12.0 and newer). 

The example below shows how an encrypted enable secret setting would appear 
in an off-line configuration file. You can obtain the encrypted string by setting the 
password manually on the router console, then displaying the running configuration, 
and then copying and pasting the encrypted string into your offline configuration file. 

! set the enable secret password using MD5 encryption 

enable secret 5 $l$fIFcs$D.IgcsUnsgtLaWgskteq.8 


Local and Remote Administration 

Section 4.1.3 recommends performing local administration. In this case, using the 
terminal is the best choice for loading a new configuration. The configuration files 
would be stored on the computer attached to the console and the local machine’s 
copy/paste buffer can be used for transferring the configuration to the router. Only a 
few lines should be copied at a time so it can be determined that the entire 
configuration file is transferred successfully. [Note: the default Windows NT 4.0 
serial communication program. Hyperterminal, performs copy/paste very slowly. On 
Windows NT and 2000, use a better communication program, such as TeraTerm Pro, 
if you have one available. On Linux, the minicom program is suitable for Cisco local 
console access. On Solaris, the tip command can be used] 

If remote administration is being allowed and the router is mnning an lOS older than 
version 12.0 then using the console connection or a telnet connection is the best 
choice for administration. The file would again be transferred using the host systems 
copy/paste buffer to move the information from a file editor to the terminal 
emulation. 

If remote administration is allowed and the lOS is newer then version 12.0 then the 
FTP protocol may be used to transfer the configuration files to and from the router. 
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The following example shows how to save the startup configuration to a file (for 
emergencies only, not recommended between lOS versions). 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# ip ftp username nsmith 

Central(config)# ip ftp password lpace-4ward 

Central(config)# exit 

Central# copy startup-config ftp: 

Address or name of remote host []? 14.2.9.1 

Destination filename [startup-config]? /cisco/central/startup- 
config 

Writing startup-config ! ! 

5516 bytes copied in 12.352 secs (459 bytes/sec) 

Central# 


The next example demonstrates how to load a new configuration to the startup 
configuration. Before loading a configuration this way make sure that all the 
configurations in the NVRAM have been saved. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# ip ftp username nsmith 
Central(config)# ip ftp password lpace-4ward 

Central(config)# exit 

Central# copy /erase ftp: startup-config 

Address or name of remote host []? 14.2.9.1 
Source filename []? /cisco/central/startup-config 

Destination filename [startup-config]? 

Accessing ftp://14.2.9.1/cisco/central/startup-config... 

Erasing the nvram filesystem will remove all files! Continue? 
[confirm] 

[OK] 

Erase of nvram: complete 

Loading /cisco/central/startup-config ! 
central-startup-config ! 

[OK - 5516/1024 bytes] 

[OK] 

5516 bytes copied in 4.364 secs 
Central# 

The other protocols, such as rep and tftp, are less secure than FTP and should not be 
used for loading or saving router configurations. See Section 4.5.5 for details on 
using tftp if required. 

4.1.8. References 

[1] Cisco lOS Release 12.0 Security Configuration Guide, Cisco Press, 1999. 

This is the reference manual and guide for major security features in lOS 
12.0. Sections particularly relevant to Router Access Security include: 
Security Overview, Configuring Passwords and Privileges, and Traffic 
Filtering and Firewalls. 
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[2] Buckley, A. ed. Cisco lOS 12.0 Configuration Fundamentals, Cisco Press, 1999. 

This is the reference manual and guide for basic configuration tasks in lOS 
12.0. Sections particularly relevant to Router Access Security include: lOS 
User Interfaces and File Management. 

[3] Albritton, J. Cisco lOS Essentials, McGraw-Hill, 1999. 

An excellent introduction to basic usage and configuration of lOS routers. 

[4] “Password Usage” Federal Information Processing Standard Publication 112, 
National Institute of Standards and Technology, 1985. 

This federal standard includes some good guidelines on choosing passwords 
that are difficult to guess. 
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4.2. Router Network Service Security 

Cisco routers support a large number of network services at layers 2, 3, 4, and 7, 
Some of these services can be restricted or disabled, improving security without 
degrading the operational use of the router. Some of these services are application 
layer protocols that allow users and host processes to connect to the router. Others 
are automatic processes and settings intended to support legacy or specialized 
configurations but which are detrimental to secure. As stated in Section 3, general 
security practice for routers should be to support only traffic and protocols the 
network needs; most of the services listed below are not needed. 

Turning off a network service on the router itself does not prevent it from supporting 
a network where that protocol is employed. For example, a router may support a 
network where the bootp protocol is employed, but some other host is acting as the 
bootp server. In this case, the router’s bootp server should be disabled. 

In many cases, Cisco lOS supports turning a service off entirely, or restricting access 
to particular network segments or sets of hosts. If a particular portion of a network 
needs a service but the rest does not, then the restriction features should be employed 
to limit the scope of the service. 

Turning off an automatic network feature usually prevents a certain kind of network 
traffic from being processed by the router or prevents it from traversing the router. 
For example, IP source routing is a little -used feature of IP that can be utilized in 
network attacks. Unless it is required for the network to operate, IP source routing 
should be disabled. 

4.2.1. Typical Services, Required Services, and Security Risks 

The table below lists some of the services offered on Cisco lOS 11.2, 11.3, and 12.0. 
This list has been kept short by including only those services and features that are 
security-relevant and may need to be disabled. 

Table 4-1: Overview of lOS Features to Disable or Restrict 


Feature Description Default Recommendation 


Cisco Discovery 
Protocol (CDP) 

Proprietary layer 2 protocol 
between Cisco devices. 

Enabled 

CDP is almost never 
needed, disable it. 

TCP small servers 

Standard TCP network 
services: echo, chargen, etc. 

11.3: disabled 

11.2: enabled 

This is a legacy feature, 
disable it explicitly. 

UDP small 

servers 

Standard UDP network 
services: echo, discard, etc. 

11.3: disabled 

11.2: enabled 

This is a legacy feature, 
disable it explicitly. 

Finger 

Unix user lookup service, 
allows remote listing of 
users. 

Enabled 

Unauthorized persons 
don’t need to know this, 
disable it. 
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Feature Description Default Recommendation 


HTTP server 

Some Cisco lOS devices 
offer web-based 
configuration. 

Varies by 
device 

If not in use, explicitly 
disable, otherwise restrict 

access. 

Bootp server 

Service to allow other 

routers to boot from this 

one. 

Enabled 

This is rarely needed and 
may open a security hole, 
disable it. 

Configuration 

auto-loading 

Router will attempt to load 
its configuration via TFTP. 

Disabled 

This is rarely used, disable 
it if it is not in use. 

IP source routing 

IP feature that allows 
packets to specify their own 
routes. 

Enabled 

This rarely -used feature 
can be helpful in attacks, 
disable it. 

Proxy ARP 

Router will act as a proxy 
for layer 2 address 
resolution. 

Enabled 

Disable this, unless the 
router is serving as a LAN 
bridge. 

IP directed 

broadcast 

Packets can identify a target 
LAN for broadcasts. 

Enabled 

Directed broadcast can be 
used for attacks, disable it. 

Classless routing 
behavior 

Router will forward packets 
with no concrete route. 

Enabled 

Certain attacks can benefit 
from this: disable it unless 
your net requires it. 

IP subnet zero 
support 

Router will support the 
illegal zero-bit mask. 

Disabled 

Explicitly disable this. 

IP unreachable 

notifications 

Router will explicitly notify 
senders of incorrect IP 
addresses. 

Enabled 

Can aid network mapping, 
disable on interfaces to 
untrusted networks. 

IP mask reply 

Router will send an 
interface’s IP address mask 
in response to an ICMP 
mask request. 

Disabled 

Can aid IP address 
mapping; explicitly dis able 
on interfaces to untrusted 
networks. 

IP redirects 

Router will send an ICMP 
redirect message in response 
to certain routed IP packets. 

Enabled 

Can aid network mapping, 
disable on interfaces to 
untrusted networks. 

NTP service 

Router can act as a time 
server for other devices and 

hosts. 

Enabled if 
NTP is in use 

If not in use, explicitly 
disable, otherwise restrict 

access. 

Simple Network 
Mgmt. Protocol 

Routers can support SNMP 
remote query and 
configuration. 

Enabled 

If not in use, explicitly 
disable, otherwise restrict 

access. 

Domain Name 

Service 

Routers can perform DNS 
name resolution. 

Enabled 

(broadcast) 

Set the DNS server address 
explicitly, or disable DNS. 
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4.2.2. How to Disable Unneeded Features and Services 

Each sub-section below describes how to disable or restrict particular services and 
features under Cisco lOS 11.3 and 12.0. 

CDP 


The Cisco Discovery Protocol is a proprietary protocol that Cisco routers use to 
identify each other on a LAN segment. It is useful only in specialized situations, and 
is considered deleterious to security. To turn off CDP entirely, use the commands 
shown below in global configuration mode. 

Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# no cdp run 
Central(config)# exit 
Central# show cdp 
% CDP is not enabled 

In the unlikely event that CDP is needed for part of a network, it can be enabled and 
disabled for each interface. To enable CDP use the cdp run command in global 
configuration mode, and then disable it on each interface where it is not needed using 
the no cdp enable command in interface configuration mode. 


TCP and UDP Small Servers 

The TCP and UDP protocol standards include a recommended list of simple services 
that hosts should provide. In virtually all cases, it is not necessary for routers to 
support these services, and they should be disabled. The example below shows how 
to test whether the TCP small servers are running, and how to disable the TCP and 
UDP small servers. 

Central# ! if connect success, then tcp-small-servers are running 
Central# connect 14.2.9.250 daytime 

Trying 14.2.9.250, 13 ... Open 

Monday, April 3, 2000 11:48:39-EDT 
[Connection to 14.2.9.250 closed by foreign host] 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# no service tcp-small-servers 

Central(config)# no service udp-small-servers 

Central(config)# exit 

Central# connect 14.2.9.250 daytime 

Trying 14.2.9.250, 13 ... 

% Connection refused by remote host 
Central# 
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Finger Server 

The lOS finger server supports the Unix ‘finger’ protocol, which is used for querying 
a host about its logged in users. On a Cisco router, the show users command may 
be used to list the logged in users. Typically, users who are not authorized to log in to 
the router have no need to know who is logged in. The example below shows how to 
test and disable the finger server. 

Central# connect 14.2.9.250 finger 

Trying 14.2.9.250, 79 ... Open 
Welcome to the CENTRAL router. 

Line User Host(s) Idle Location 

130 vty 0 14.2.9.6 00:00:00 goldfish 

*131 vty 1 idle 00:00:00 central 

[Connection to 14.2.9.250 closed by foreign host] 

Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# no ip finger 
Central(config)# no service finger 
Central (config)# exit 
Central# connect 14.2.9.250 finger 

Trying 14.2.9.250, 79 ... 

% Connection refused by remote host 
Central# 


HTTP Server 

Newer Cisco lOS releases support web-based remote administration using the HTTP 
protocol. While the web access features are fairly rudimentary on most Cisco router 
lOS releases, they are a viable mechanism for monitoring, configuring, and attacking 
a router. If web-based remote administration is not needed, then it should be disabled 
as shown below. 

Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central (config)# no ip http server 

Central(config)# exit 

Central# connect 14.2.9.250 www 

Trying 14.2.9.250, 80 ... 

% Connection refused by remote host 
Central# 

Web-based remote administration is useful primarily when intervening routers or 
firewalls prevent use of Telnet for that purpose. However, it is important to note that 
both Telnet and web-based remote administration reveal critical passwords in the 
clear. Further, web-based administration imposes the requirement that users log in at 
full (level 15) privilege. Therefore, web-based remote administration should be 
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avoided. If web-based administration is examined and found necessary for network 
operations, then its use should be restricted as follows. 


■ Set up usernames and passwords for all administrators, as discussed in 
Section 4.1. The router’s web server will use HTTP basic authentication 
to demand a username and password (unfortunately, Cisco lOS does not 
yet support the superior HTTP digest authentication standard). If possible, 
use AAA user access control as described in Section 4.6; AAA will give 
more control and better audit. 

■ Create and apply an IP access list to limit access to the web server. Access 
lists are described in Section 4.3. 

■ Enable syslog logging as described in Section 4.5.2. 


The example below illustrates each of these points. Administrators will be allowed 
to connect from the 14.2.9.0 network and the host 14.2.6.18 only. 


Central# config t 

Enter configuration commands, one per line. 


End with CNTL/Z. 


Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central (config)# 
Central# 


! Add web admin users, then turn on http auth 
username nzWeb priv 15 password 0 C5-AlrCargO 
ip http auth local 

! Create an IP access list for web access 
no access-list 29 

access-list 29 permit host 14.2.6.18 
access-list 29 permit 14.2.9.0 0.0.0.255 
access-list 29 deny any 

! Apply the access list then start the server 
ip http access-class 29 
ip http server 
exit 


Bootp Server 

Bootp is a datagram protocol that is used by some hosts to load their operating 
system over the network. Cisco routers are capable of acting as bootp servers, 
primarily for other Cisco hardware. This facility is intended to support a deployment 
strategy where one Cisco router acts as the central repository of lOS software for a 
collection of such routers. In practice, bootp is very rarely used, and offers an 
attacker the ability to download a copy of a router’s lOS software. To disable bootp 
service, use the commands shown below. 


Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# no ip bootp server 

Central(config)# exit 

Central# 


Version l.Og 


UNCLASSIFIED 


63 





Router Security Configuration Guide 


UNCLASSIFIED 


Configuration Auto-Loading 

Cisco routers are capable of loading their startup configuration from local memory or 
from the network. Loading from the network is not secure, and should be considered 
only on a network that is wholly trusted (e.g. a standalone lab network). Explicitly 
disable loading the startup configuration from the network using the commands 
shown below. 

Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# no boot network 
Central(config)# no service config 
Central(config)# exit 
Central# 


IP Source Routing 

Source routing is a feature of IP whereby individual packets can specify routes. This 
feature is used in several kinds of attacks. Cisco routers normally accept and process 
source routes. Unless a network depends on source routing, it should be disabled on 
all the net’s routers. The example below shows how to disable IP source routing. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# no ip source-route 
Central(config)# exit 
Central# 


Proxy ARP 

Network hosts use the Address Resolution Protocol (ARP) to translate network 
addresses into media addresses. Normally, ARP transactions are confined to a 
particular LAN segment. A Cisco router can act as intermediary for ARP, 
responding to ARP queries on selected interfaces and thus enabling transparent 
access between multiple LAN segments. This service is called proxy ARP. Because 
it breaks the LAN security perimeter, effectively extending a LAN at layer 2 across 
multiple segments, proxy ARP should be used only between two LAN segments at 
the same tmst level, and only when absolutely necessary to support legacy network 
architectures. 

Cisco routers perform proxy ARP by default on all IP interfaces. Disable it on each 
interface where it is not needed, even on interfaces that are currently idle, using the 
command interface configuration command no ip proxy-arp . The example 
below shows how to disable proxy ARP on four Ethernet interfaces. 

Central# show ip interface brief 

Interface IP-Address OK? Method Status Protocol 

Ethernet0/0 14.1.15.250 YES NVRAM up up 
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EthernetO/l 

14.2.9.250 

YES 

NVRAM 

up 

up 

EthernetO/2 

unassigned 

YES 

unset 

down 

down 

EthernetO/3 

unassigned 

YES 

unset 

down 

down 


Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# interface eth 0/0 

Central(config-if)# no ip proxy-arp 

Central(config-if)# exit 

Central(config)# interface eth 0/1 

Central(config-if)# no ip proxy-arp 

Central(config-if)# exit 

Central(config)# interface eth 0/2 

Central(config-if)# no ip proxy-arp 

Central(config-if)# exit 

Central(config)# interface eth 0/3 

Central(config-if)# no ip proxy-arp 

Central(config-if)# end 

Central# 


IP Directed Broadcast and Subnet-zero Support 

Directed broadcasts permit a host on one LAN segment to initiate a physical 
broadcast on a different LAN segment. This technique was used in some old denial 
of-service attacks, and the default Cisco lOS configuration is to reject directed 
broadcasts. Explicitly disable directed broadcasts on each interface using the 
interface configuration command no ip directed-broadcast . 

IP subnets with an address of 0 are illegal and strongly discouraged in the IP 
standard. For example, a network with an address of 14.2.0.0/24 has a subnet address 
of 0 in the third octet. The default Cisco lOS configuration is to reject subnet-zero 
packets. Explicitly prohibit such packets using the no ip subnet-zero command. 

IP Classless Routing 

By default, a Cisco router will make an attempt to route almost any IP packet. If a 
packet arrives addressed to a subnet of a network that has no default network route, 
then lOS will, with IP classless routing, forward the packet along the best available 
route to a supemet of the addressed subnet. This feature is often not needed. On 
routers where IP classless routing is not needed, disable it as shown below. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config) # no ip classless 
Central(config) # exit 


IP Unreachables, Redirects, Mask Replies 

The Internet Control Message Protocol (ICMP) supports IP traffic by relaying 
information about paths, routes, and network conditions. Cisco routers automatically 
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send ICMP messages under a wide variety of conditions. Three ICMP messages are 
commonly used by attackers for network mapping and diagnosis: ‘Host unreachable’, 
‘Redirect’, and ‘Mask Reply’. Automatic generation of these messages should be 
disabled on all interfaces, especially interfaces that are connected to untrusted 
networks. The example below shows how to turn them off for an interface. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# interface eth 0/0 

Central(config-if)# no ip unreachable 

Central(config-if)# no ip redirect 

Central(config-if)# no ip mask-reply 

Central(config-if)# end 

Central# 

NTP Service 

Cisco routers and other hosts use the Network Time Protocol (NTP) to keep their 
time-of-day clocks accurate and in synchrony. If possible, configure all routers as 
part of an NTP hierarchy, as described in Section 4.5. If an NTP hierarchy is not 
available on the network, then disable NTP as shown below. 

North# show ip interface brief 

Interface IP-Address OK? Method Status Protocol 

EthernetO/0 14.2.10.20 YES NVRAM up up 

Ethernet1/0 14.1.1.250 YES NVRAM up up 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# interface eth 0/0 

North(config-if)# no ntp enable 

North(config-if)# exit 

North(config)# interface eth 1/0 

North(config-if)# no ntp enable 

North(config-if)# end 

North# 

Disabling NTP on an interface will not prevent NTP messages from traversing the 
router. To reject all NTP messages at a particular interface, use an access list, as 
discussed in Section 4.3. 

SNMP Services 

The Simple Network Management Protocol (SNMP) is the standard Internet protocol 
for automated remote monitoring and administration. There are several different 
versions of SNMP, with different security properties. If a network has a deployed 
SNMP infrastmcture in place for administration, then all routers on that network 
should be configured to securely participate in it. In the absence of a deployed SNMP 
scheme, all SNMP facilities on all routers should be disabled using these steps: 
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■ Erase existing community strings, and set a hard-to-guess, read-only 
community string. 

■ Apply a simple IP access list to SNMP denying all traffic. 

■ Disable SNMP system shutdown and trap features. 

■ Disable SNMP system processing. 

The example below shows how to disable SNMP by implementing these 
recommendations. It starts with listing the current configuration to find the SNMP 
community strings. The configuration listing is often quite long, but there is no other 
mechanism in Cisco lOS for viewing the configured SNMP community strings. 

Central# show running-config 

Building configuration... 


snmp-server community public RO 
snmp-server community admin RW 


Central# 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# ! remove old community strings 

Central (config) # no snmp community public RO 

Central(config) # no snmp community admin RW 

Central(config)# ! create a very restrictive access list 

Central(config) # no access-list 70 

Central(config) # access-list 70 deny any 

Central(config) # ! make SNMP read-only and subject to access list 

Central (config) # snmp community aqiytjl726540942 ro 70 

Central(config) # ! disable SNMP trap and system-shutdown features 

Central(config) # no snmp enable traps 

Central(config) # no snmp system-shutdown 

Central(config) # no snmp trap-auth 

Central(config) # ! disable the SNMP service 

Central(config) # no snmp-server 

Central(config) # end 

The last command in the example, no snmp-server, shuts down all SNMP 
processing on the router. While SNMP processing is shut down, SNMP 
configuration will not appear in any listing of the mnning configuration, but it can 
still be there! The safest way to ensure that SNMP is really unavailable to an 
attacker, and will remain so, is to follow the full course of commands listed above 
and in the configuration example. 

For information on setting up and using SNMP securely, see Section 4.5.3. 
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DNS Name Resolution 

Cisco lOS supports looking up host names with DNS. By default, name queries are 
sent to the broadcast address 255.255.255.255. If one or more name servers are 
available on the network, and you want to be able to use names in lOS commands, 
then explicitly set the name server addresses using the global configuration command 
ip name-server addresses. Otherwise, turn off DNS name resolution with the 
command no ip name-server. The example below shows how to set up a main 
and backup DNS server address for the router Central. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# ip name-server 14.1.1.2 14.2.9.1 

Central(config)# end 


4.2.3. Configuration Example 

The configuration listing below shows the configuration commands for disabling 
typical unneeded services, as described above. This sample is formatted as it would 
appear in a configuration text file stored on a host for download to the router Central. 
For more information about NTP and SNMP security configuration, see section 4.5. 

! - IP and network services Section 

no cdp run 

no ip subnet-zero 

no ip source-route 

no ip classless 

no service tcp-small-serv 

no service udp-small-serv 

no ip finger 

no service finger 

no ip bootp server 

no ip http server 

no ip name-server 

! - Boot control section 

no boot network 
no service config 

! - SNMP Section (for totally disabling SNMP) 

! set up totally restrictive access list 
no access-list 70 
access-list 70 deny any 

! make SNMP read-only and subject to access list 
snmp-server community aqiytjl726540942 ro 11 
! disable SNMP trap and system-shutdown features 
no snmp-server enable traps 
no snmp-server system-shutdown 
no snmp-server trap-auth 
! turn off SNMP altogether 
no snmp-server 
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! - Per-interface services section 

interface eth 0/0 

description Outside interface to 14.1.0.0/16 net 

no ip proxy-arp 

no ip directed-broadcast 

no ip unreachable 

no ip redirect 

no ntp enable 

exit 

interface eth 0/1 

description Inside interface to 14.2.9.0/24 net 

no ip proxy-arp 

no ip directed-broadcast 

no ip unreachable 

no ip redirect 

no ntp enable 

exit 

interface eth 0/2 
no ip proxy-arp 
exit 

interface eth 0/3 
no ip proxy-arp 
exit 


4.2.4. References 

[1] Eldridge, B. “Building Bastion Routers Using Cisco lOS,” PhrackMagazine, 
Vol. 9 Issue 55, September 1999. 

available at: http : //www . phrack . com/search . phtml ?issueno=55&r=0 

A concise and readable article with practical advice on setting up a router at a 
boundary between a trusted and untrusted network. 

[2] “Cisco lOS Version 12.0 Security Configuration,” National Y2K Information 
Coordination Center, September 1999. 
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[3] “Increasing Security on IP Networks,” , Cisco Internetworking Case Studies, 
Cisco Systems, 1998. 

available under: 
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routers mnning lOS 11.3. Available from Cisco’s web site. 
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The sections on “Perfomiing Basic System Management” and “Monitoring 
the Router and Network” include valuable advice on how to configure basic 
features and services. 

[5] Cisco lOS Network Protocols Configuration Guide, Part 1, Cisco Press, 1999. 

The section on “IP Addressing and Services” includes information about 
several of the IP services described in this section. 

[6] Held, G. and Hundley, K. Cisco Security Architectures, McGraw-Hill, New 
York, 1999. 

Good overview of Cisco router and TCP/IP architecture, plus excellent 
coverage of access lists. 

[7] Franks, J. et. al. "HTTP Authentication: Basic and Digest Access 
Authentication", RFC 2617, June 1999. 

The standard for HTTP basic authentication used for access control by Cisco 
lOS web remote administration. 
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4.3. Access Lists and Filtering 

Cisco lOS uses access lists to separate data traffic into that which it will process 
(permitted packets) and that which it will not process (denied packets). Secure 
configuration of Cisco routers makes very heavy use of access lists, for restricting 
access to services on the router itself, and for filtering traffic passing through the 
router. This section gives a moderately detailed description of access list syntax, 
with some extensive examples. 

4.3.1. Concepts 

Access lists on Cisco routers provide packet filtering capability. An access list 
contains one or more rules. For IP traffic, there are two types of access lists 
available: standard and extended. Standard access lists only allow source IP address 
filtering. Extended access lists can permit or deny packets based on their protocols, 
source or destination IP addresses, source or destination TCP/UDP ports, or ICMP or 
IGMP message types. Extended access lists also support selective logging. Both 
standard and extended IP access lists can be applied to router interfaces, vty lines (for 
remote access), IPSec, and routing protocols. Only standard IP access lists can be 
applied to SNMP. 

Syntax 

The basic structure for an access list mle is shown below. 

Sicctss-Xvsiaccess-list-number {deny I permit} condition 

The access list number tells Cisco lOS which access list the rule should be a part of, 
and what kind of access list it is. The condition field, which is different for each kind 
of access list, specifies which packets match the mle. Conditions typically involve 
protocol information and addresses, but do not involve application-level information. 

The following is the syntax for a statement (mle) in a standard IP access list: 

acctss-Xisiaccess-list-number (deny I permit} source [source-wildcard] 

where access-list-number is the number of the access list and can be any 
decimal number from 1 to 99. 

deny denies access if the condition is matched. 

permit permits access if the condition is matched. 

source is the IP address of the network or host from which the packet 
is being sent. 

source-wildcard is the wildcard bits to be applied to the source. 
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The following is simplified syntax for a statement in an extended IP access list: 

sic.cess-\\siaccess-list-number {deny I permit} protocol 
source source-wildcard source-qualifiers 
destination destination-wildcard destination-qualifiers [ log ] 

where access-list-number is the number of the access list and can be any 
decimal number from 100 to 199. 

deny denies access if the condition is matched. 

permit permits access if the condition is matched. 

protocol is the name or number of an IP -related protocol. It can be 
one of the following keywords: eigrp, gre, icmp, igmp, igrp, ip, 
ipinip, nos, ospf, tcp or udp. Or it can be an integer in the range 0 to 
255 representing an IP protocol number. (Some protocols allow 
further qualifiers: source or destination ports can be specified for tcp 
or udp, and message types can be specified for icmp or igmp.) 

source is the IP address of the network or host from which the packet 
is being sent. 

source-wildcard is the wildcard bits to be applied to the source. The 
keyword any can be used in place of source and source-wildcard. 

source-qualifiers are further details on the packet source, including 
port numbers and other protocol-specific information. Use of the 
qualifiers is optional. 

destination is the IP address of the network or host to which the 
packet is being sent. 

destination-wildcard is the IP address wildcard bits to be applied to 
the destination. The keyword any can be used in place of destination 
and destination-wildcard. 

destination-qualifiers are further details on the packet destination, 
including port numbers and other protocol-specific information. Use 
of the qualifiers is optional. 

log, if present, causes an informational message about the packet that 
matches the statement to be logged (see Section 4.5.1). 

Cisco has also created an alternative called named IP access lists for both standard 
and extended lists. This feature allows you to refer to an access list by name instead 
of by number. It also provides a convenient way to build lists on-line. The syntax 
for defining an IP access list by name is shown below. After the list is defined by 
name, one creates statements beginning with either the permit or deny keyword. 
After the permit or deny keyword the syntax is the same as defined above for either 
the standard list or the extended list. 
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ip access-list {standard I extended} name 

where standard specifies a standard IP access list. 

extended specifies an extended IP access list. 

name is the name of the access list. The name cannot contain spaces 
or punctuation and must begin with an alphabetic character. 

General Recommendations 

Refer to the two tables in Section 3.2.2 that present common services to restrict 
because they can be used to gather information about an internal network or they 
have weaknesses that can be exploited. The first table lists those services that should 
be completely blocked at the router; they should not be allowed across the router in 
either direction or to the router. The second table lists those services on the internal 
network or on the router that should not be accessible by external clients. 

In each access list there must be at least one permit statement. Otherwise, an access 
list with no permit statements will block all network traffic wherever it is applied. 

Note that an access list is applied to packets traveling in one direction only. For any 
connection that requires two-way interaction (e.g., all TCP traffic, some UDP traffic) 
the access list will only affect approximately half the packets. It is possible however 
to apply two access lists (one for each direction) for router interfaces, vty lines and 
routing protocols. The diagram below shows how access lists work when applied to 
router interfaces, using the router East as an example. 



Outbound 
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Outbound 

Access 

-- 


Access 

List 




List 


Figure 4-2: Conceptual Model for Access Lists on Interfaces 
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Use the log keyword at the end of each deny statement in each extended access list, 
as shown in the example below. This feature will provide valuable information 
about what types of packets are being denied. Logs of denied packets can be useful 
for detection and analysis of probes and attacks against a network. Section 4.5.1 
describes lOS’s logging features in more detail. 

East(config) # access—list 102 permit ip 14.2.6.0 0.0.0.255 any 
East(config) # access-list 102 deny ip any any log 


Add the following statements at the end of each extended IP access list to deny and to 
log any packets that are not permitted. These statements will guarantee that the 
router will log the values for the source and destination ports for TCP and UDP 
traffic. 

East(config) # access-list 100 deny tcp any range 0 65535 any range 0 65535 
log 

East(config) # access—list 100 deny udp any range 0 65535 any range 0 65535 
log 

East(config) # access-list 100 deny ip any any log 


Finally, due to limited editing capability on the Cisco router, you cannot easily 
modify access lists. Thus, whenever you needs to change an access list, it is best to 
build it offline on a separate computer. When the access list is ready you can cut and 
paste the access list via a connection to the router. Since the original access list is 
still on the router, you must purge it before adding the updated access list. Below is 
an example of how to clear an access list. 

East(config) # no access—list 100 


4.3.2. Filtering Traffic to Router Itself 

Access lists are used in a variety of ways to control access to services on the router 
itself. While it is possible to incorporate access controls for these services into the 
access lists placed on interfaces, it is typically easier and more reliable to use the 
specialized facilities that lOS makes available to apply access controls directly to the 
services themselves. For more information about services on the router, and how to 
disable unneeded ones, see Section 4.2. 


Remote Login (Telnet) Service 

There are a number of methods to filter access to the router itself: vty lines, SNMP 
servers and routing protocols. The vty lines are used for remote access to the router. 
Typically, a router administrator telnets to one of the vty lines. The following 
example shows the configuration of an extended IP access list that is applied to the 
vty lines. This simple IP access list allows the hosts with IP addresses 14.2.6.1 and 
14.2.6.18 to connect to the router East via Telnet. The list denies all other 
connections. It also logs all successful and unsuccessful connections. 
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East(config)# access-list 105 permit host 14.2.6.1 any eq 23 log 
East(config)# access—list 105 permit tcp host 14.2.6.18 any eq 23 log 
East(config)# access—list 105 deny ip any any log 

East (config)# line vty 0 4 

East(config-line)# access-class 105 in 

East(config-line)# end 


SNMP Service 

A Cisco router can be configured to act as a client for SNMP. Whe n SNMP service 
is enabled on a router, network management tools can use it to gather information 
about the router configuration, route table, traffic load, and more. Versions 1 and 2 
of SNMP are not considered very secure due to the lack of strong authentication. 
Thus, SNMP be used only on the internal or protected network. The following 
example shows the configuration of a standard IP access list that is applied to a snmp 
server. This access list allows the host with IP address 14.2.6.6 to gather SNMP 
information from the router. The list denies all other connections. 

East(config)# access-list 75 permit host 14.2.6.6 

East(config)# snmp-server community n3t-manag3m3nt ro 75 


For more information about SNMP configuration, see Sections 4.2.2 and 4.5.3. 

OSPF Service 

Communications between routers for routing table updates involve routing protocols. 
These updates provide directions to a router on which way traffic should be routed. 
You can use access lists to restrict what routes the router will accept (in) or advertise 
(out) via routing protocols. The following example shows the configuration of an 
extended IP access list applied to the OSPF routing protocol, area 1. With the access 
list applied, router North will not advertise routes to the 14.2.9.0 network. 

North(config)# access-list 10 deny 14.2.9.0 0.0.0.255 any 
North(config)# access-list 10 permit any 

North(config)# router ospf 1 

North(config-router)# distribute-list 10 out 
North(config-router)# end 

For more information about OSPF security configuration, see Section 4.4. 


4.3.3. Filtering Traffic through the Router 

The following examples illustrate methods to protect the router or the internal 
network from attacks. Note: these separate examples should not be combined into 
one access list because the result would contain contradictions. In the next section an 
example configuration file is presented that shows one way to combine these 
methods into access lists. Refer to the network diagram in Figure 4-1 to understand 
the example interfaces, their IP addresses and the corresponding access lists. 
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IP Address Spoof Protection 


Inbound Traffic 


Do not allow any inbound IP packet that contains an IP address from the internal 
network (e.g., 14.2.6.0), any local host address (127.X.X.X), the link-local DHCP 
default address (169.254.0.0), or any reserved private addresses (refer to RFC 1918) 
in the source field. Apply this access list to the external interface of the router, as 
shown in the transcript below. 


East(config)# access—list 100 deny ip 14.2.6.0 0.0.0.255 

East(config)# access—list 100 deny ip 127.0.0.0 0.255.255.255 

East(config)# access-list 100 deny ip 10.0.0.0 0.255.255.255 

East(config)# access—list 100 deny ip 172.16.0.0 0.15.255.255 

East(config)# access—list 100 deny ip 192.168.0.0 0.0.255.255 

East(config)# access—list 100 deny ip 169.254.0.0 0.0.255.255 

East(config)# access—list 100 permit ip any 14.2.6.0 0.0.0.255 
East(config)# interface ethO/0 

East(config-if)# description "external interface" 

East(config-if)# ip address 14.1.1.20 255.255.0.0 
East(config-if)# ip access-group 100 in 
East(config-if)# exit 
East(config)# interface ethO/1 

East(config-if)# description "internal interface" 

East(config-if)# ip address 14.2.6.250 255.255.255.0 

East(config-if)# end 


any log 
any log 
any log 
any log 
any log 
any log 


Outbound Traffic 

Do not allow any outbound IP packet that contains an external IP address in the 
source field. Apply this access list to the internal interface of the router. See 
example rules below. 

East(config)# no access—list 102 

East(config)# access—list 102 permit ip 14.2.6.0 0.0.0.255 any 
East(config)# access-list 102 deny ip any any log 
East(config)# interface eth 0/1 

East(config-if)# description "internal interface" 

East(config-if)# ip address 14.2.6.250 255.255.255.0 
East(config-if)# ip access—group 102 in 


On most Cisco routers, lOS 12 offers an another mechanism for IP address spoof 
protection: IP reverse-path forwarding verification. Though specialized, and not 
suitable for all networks, this facility offers good performance and ease of 
maintenance. Section 4.4.5 shows how to set up reverse-path forwarding verification 
on routers that support it. 
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Exploits Protection 

This sub-section describes how to use access lists to defeat or discourage several 
common attacks using lOS traffic filtering capabilities. 


TCP SYN Attack 

The TCP SYN Attack involves transmitting a volume of connections that cannot be 
completed at the destination. This attack causes the connection queues to fill up, 
thereby denying service to le gitimate TCP users. The following shows two different 
scenarios. 

External Access Blocked 

The access list rules shown below will block packets from an external network that 
have only the SYN flag set. Thus, it allows traffic from TCP connections that were 
established from the internal network, and it denies anyone coming from any external 
network from starting any TCP connection. 

East(config) # access—list 106 permit tcp any 14.2.6.0 0.0.0.255 established 
East(config) # access-list 106 deny ip any any log 
East(config) # interface eth 0/0 

East(config-if )# description "external interface" 

East(config-if )# ip access-group 106 in 


Limiting External Access with TCP Intercept 

The access list mles shown below will block packets from unreachable hosts using 
the TCP intercept feature; thus, it only allows reachable external hosts to initiate 
connections to a host on the internal network. In intercept mode the router intercepts 
each TCP connection establishment, and determines if the address from which the 
connection is being initiated is reachable. If the host is reachable, the router allows 
the connection to be established; otherwise, it prevents the connection. 

East(config) # ip tcp intercept list 107 

East(config) # access-list 107 permit tcp any 14.2.6.0 0.0.0.255 
East(config) # access-list 107 deny ip any any log 
East(config) # interface eth 0/0 

East(config-if) # description "external interface" 

East(config-if )# ip access-group 107 in 


Tcp intercept is a very effective mechanism for protecting hosts on a network from 
outside TCP SYN attacks, for extensive details consult the Cisco lOS 12 Security 
Configuration Guide [5]. However, the tcp intercept feature is available in most, but 
not all, Cisco lOS version 11.3 and 12.0 releases. 
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Land Attack 


The Land Attack involves sending a packet to the router with the same IP address in 
the source address and destination address fields and with the same port number in 
the source port and destination port fields. This attack may cause a denial of service 
or degraded capability in the router. The example below shows how to prevent this 
attack. 


East(config) # access-list 100 deny ip host 14.1.1.20 
host 14.1.1.20 log 

East(config) # access-list 100 permit ip any any 
East(config) # interface ethO/0 

East(config-if )# description "external interface to 14.1.0.0/16" 
East(config-if )# ip address 194.168.20.20 255.255.255.0 
East(config-if )# ip access-group 100 in 

East(config-if )# end 
East# 


Smurf Attack 

The Smurf Attack involves sending a large amount of ICMP Echo packets to a 
subnet's broadcast address with a spoofed source IP address from that subnet. If a 
router is positioned to forward broadcast requests to other routers on the protected 
network, then the router should be configured to prevent this forwarding from 
occurring. This blocking can be achieved by denying any packets destined for 
broadcast addresses. The example statements below block all IP traffic from any 
host to the possible broadcast addresses (194.168.255.255 and 194.168.0.0) for the 
194.168 subnet. 

East(config) # access-list 110 deny ip any host 194.168.255.255 log 
East(config) # access-list 110 deny ip any host 194.168.0.0 log 

ICMP Message Types and Traceroute 

There are a variety of ICMP message types. Some are associated with programs. For 
example, the ping program works with message types Echo and Echo Reply. Others 
are used for network management and are automatically generated and interpreted by 
network devices. For inbound ICMP traffic, block the message types Echo and 
Redirect. With Echo packets an attacker can create a map of the subnets and hosts 
behind the router. Also, he can perform a denial of service attack by flooding the 
router or internal hosts with Echo packets. With ICMP Redirect packets the attacker 
can cause changes to a host’s routing tables. Otherwise, the other ICMP message 
types should be allowed inbound. See the example below for inbound ICMP traffic. 


East ( config)# 

access-list 

100 

deny 

icmp 

any 

any echo 

log 

East ( config)# 

access-list 

100 

deny 

icmp 

any 

14.2.6.0 

0.0.255.255 

redirect log 

East ( config)# 

access-list 

100 

permit 

icmp 

any 

14.2.6.0 

0.0.255.255 
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For outbound ICMP traffic, one should allow the message types Echo, Parameter 
Problem and Source Quench and block all other message types. With Echo packets 
users will be able to ping external hosts. Parameter Problem packets and Source 
Quench packets improve connections by informing about problems with packet 
headers and by slowing down traffic when it is necessary. See the example below for 
outbound ICMP traffic. 


East(config)# 
East(config)# 
East(config)# 
East(config)# 


access-list 102 permit 
any echo 

access-list 102 permit 
any parameter-problem 
access-list 102 permit 
any source-quench 
access-list 102 deny 


icmp 14.2.6.0 0.0.0.255 
icmp 14.2.6.0 0.0.0.255 
icmp 14.2.6.0 0.0.0.255 
icmp any any log 


Another program that deals with certain ICMP message types is traceroute. 
Traceroute is a utility that prints the IP addresses of the routers that handle a packet 
as the packet hops along the network from source to destination. On Unix and Linux 
operating systems, traceroute uses UDP packets and causes routers along the path to 
generate ICMP message types ‘Time Exceeded’ and ‘Unreachable’. An attacker can 
use traceroute response to create a map of the subnets and hosts behind the router, 
just as they could do with ping’s ICMP Echo Reply messages. Therefore, block 
inbound traceroute including a mle in the inbound interface access list, as shown in 
the example below (ports 33400 through 34400 are the UDP ports commonly used 
for traceroute). 


East(config) # access—list 100 deny udp any any range 33400 34400 log 


A router may be configured to allow outbound traceroute by adding a rule to the 
outbound interface access list, as shown in the example below. 


East(config) # access—list 102 permit udp any any range 33400 34400 log 


Distributed Denial of Service (DDoS) Attacks 

Several high-profile DDoS attacks have been observed on the Internet. While routers 
cannot prevent DDoS attacks in general, it is usually sound security practice to 
discourage the activities of specific DDoS agents (a.k.a. zombies) by adding access 
list rules that block their particular ports. The example below shows access list rules 
for blocking several popular DDoS attack tools. [Note that some of these mles may 
also impose a slight impact on normal users, because they block high-numbered ports 
that legitimate network clients may randomly select.] These rules would normally be 
applied to traffic in both directions between an internal or tmsted network and an 
untrusted network. 


! the TRINOO 

DDoS sy 

stems 






access-list 

170 

deny 

tcp 

any 

any 

eq 

27665 

log 

access-list 

170 

deny 

udp 

any 

any 

eq 

31335 

log 

access-list 

170 

deny 

udp 

any 

any 

eq 

27444 

log 
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! the Stacheldraht DDoS system 

access-list 170 deny tcp any any eq 16660 log 

access-list 170 deny tcp any any eq 65000 log 

! the TrinityVS system 

access-list 170 deny tcp any any eq 33270 log 

access-list 170 deny tcp any any eq 39168 log 

! the Subseven DDoS system and some variants 
access-list 170 deny tcp any any range 6711 6712 log 
access-list 170 deny tcp any any eq 6776 log 

access-list 170 deny tcp any any eq 6669 log 

access-list 170 deny tcp any any eq 2222 log 

access-list 170 deny tcp any any eq 7000 log 


The Tribe Flood Network (TFN) DDoS system uses ICMP Echo Reply messages, 
which are problematic to block because they are the heart of the ping program. 
Follow the directions in the ICMP sub-section, above, to prevent at least one 
direction of TFN communication. 


4.3.4. Example Configuration File 

The configuration file shown below is not a complete configuration file. Rather, it 
provides an example for using access lists on a Cisco router. The diagram below 
shows the topology that this file is based on. The security policy implemented with 
the access lists allows most traffic from the internal network to the external network. 
The policy restricts most traffic from the external network to the internal network. 



Protected 

Network 

14.2.6.0/24 


hostname East 

I 

interface EthernetO 

description Outside interface to the 14.1.0.0/16 network 
ip address 14.1.1.20 255.255.0.0 
ip access-group 100 in 

I 

interface Ethernetl 

description Inside interface to the 14.2.6.0/24 network 
ip address 14.2.6.250 255.255.255.0 
ip access-group 102 in 

I 

router ospf 44 
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network 14.1.0.0 0.0.255.255 area 0 
network 14.2.6.0 0.0.0.255 area 1 

I 

! access-list 75 applies to hosts allowed to gather SNMP info 
! from this router 
no access-list 75 

access-list 75 permit host 14.2.6.6 
access-list 75 permit host 14.2.6.18 

I 

! access-list 100 applies to traffic from external networks 
! to the internal network or to the router 
no access-list 100 


access-list 

100 

deny 

ip 

14.2 

.6.0 

0.0.0.255 any log 

access-list 

100 

deny 

ip 

host 

14.1.1 

.20 host 14.1. 

1.20 log 

access-list 

100 

deny 

ip 

127 . 

0.0.0 

0.255.255.255 

any log 

access-list 

100 

deny 

ip 

10.0 

.0.0 

0.255.255.255 

any log 

access-list 

100 

deny 

ip 

172 . 

16.0.0 

0.15.255.255 

any log 

access-list 

100 

deny 

ip 

192 . 

168.0.0 

0.0.255.255 

any log 

access-list 

100 

deny 

ip 

169. 

254.0.0 

0.0.255.255 

any log 

access-list 

100 

deny 

ip 

any 

host 14 

.2.6.255 log 


access-list 

100 

deny 

ip 

any 

host 14 

.2.6.0 log 


access-list 

100 

deny 

icmp 

any 

any echo log 


access-list 

100 

deny 

icmp 

any 

14.2.6. 

0 0.0.0.255 redirect log 

access-list 

100 

permit 

icmp 

any 

14.2.6. 

0 0.0.0.255 


access-list 

100 

permit 

ospf 

14.1 

.0.0 0. 

0.255.255 host 

14.1.1.20 

access-list 

100 

permit 

tcp 

any 

14.2.6. 

0 0.0.0.255 established 

access-list 

100 

deny 

tcp 

any 

any range 6000 6009 log 

access-list 

100 

deny 

tcp 

any 

any eq 

6667 log 


access-list 

100 

deny 

tcp 

any 

any range 12345 12346 

log 

access-list 

100 

deny 

tcp 

any 

any eq 

31337 log 


access-list 

100 

permit 

tcp 

any 

eg 20 14.2.6.0 0.0.0. 

255 gt 1023 

access-list 

100 

deny 

udp 

any 

any eq 

2049 log 


access-list 

100 

deny 

udp 

any 

any eq 

31337 log 


access-list 

100 

deny 

udp 

any 

any range 33400 34400 

log 

access-list 

100 

permit 

udp 

any 

eq 53 14.2.6.0 0.0.0. 

255 gt 1023 


access-list 100 deny tcp any range 0 65535 any range 0 65535 log 
access-list 100 deny udp any range 0 65535 any range 0 65535 log 
access-list 100 deny ip any any log 

I 

! access-list 102 applies to traffic from the internal network 
! to external networks or to the router itself 
no access-list 102 


access-list 

102 

deny 

ip 

host 

14 

.2.6.250 host 14.2.6 

.250 log 

access-list 

102 

permit 

icmp 

14.2 

.6. 

0 0.0.0 

.255 

any 

echo 



access-list 

102 

permit 

icmp 

14.2. 

,6.0 

0.0.0. 

255 

any 

parameter-problem 

access-list 

102 

permit 

icmp 

14.2 

.6. 

0 0.0.0 

.255 

any 

■ source-quench 

access-list 

102 

deny 

tcp 

any 

any 

range 

1 19 

log 




access-list 

102 

deny 

tcp 

any 

any 

eq 43 

log 





access-list 

102 

deny 

tcp 

any 

any 

eq 93 

log 





access-list 

102 

deny 

tcp 

any 

any 

range 

135 

139 

log 



access-list 

102 

deny 

tcp 

any 

any 

eq 445 

log 





access-list 

102 

deny 

tcp 

any 

any 

range 

512 

518 

log 



access-list 

102 

deny 

tcp 

any 

any 

eq 540 

log 





access-list 

102 

permit 

tcp 

14.2 

.6. 

0 0.0.0 

.255 

gt 

1023 

any It 

1024 

access-list 

102 

permit 

udp 

14.2 

.6. 

0 0.0.0 

.255 

gt 

1023 

any eq 

53 
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4.3.5. 


access-list 102 permit udp 14.2.6.0 0.0.0.255 any range 33400 
34400 log 

access-list 102 deny tcp any range 0 65535 any range 0 65535 log 

access-list 102 deny udp any range 0 65535 any range 0 65535 log 

access-list 102 deny ip any any log 

I 

! access-list 150 applies to remote access from specific hosts 
! (14.2.6.10, 14.2.6.11 and 14.2.6.12) to the router itself 

no access-list 150 

access-list 150 permit tcp host 14.2.6.6 host 0.0.0.0 eg 23 log 
access-list 150 permit tcp host 14.2.6.18 host 0.0.0.0 eq 23 log 
access-list 150 deny ip any any log 

I 

snmp-server community n3t-manag3m3nt ro 75 

I 

line vty 0 4 

access-class 150 in 

password 7 123456789012345678901234 
login 

transport input telnet 
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4.4. Routing and Routing Protocols 

“A protocol is a formal description of a set of rules and conventions that govern how 
devices on a network exchange information.”[5] This section will discuss two basic 
types of protocols, with a focus on the latter. The two types of protocols are: 

■ Routed protocols - 

These are protocols that can be routed by a router. The routed protocol 
allows the router to correctly interpret the logical network. Some examples 
of routed protocols are IP, IPX, AppbTalk, and DECnet. 

■ Routing protocols - 

“A routing protocol gathers information about available networks and the 
distance, or cost, to reach those networks.”[7] These protocols support 
routed protocols and are used to maintain routing tables. Some examples 
of routing protocols are OSPF, RIP, BGP, and IGRP. 

All of the examples in this section are based on the sample network architecture 
shown in Figure 4-1. 

Routed Protocols 


The most commonly used routed network protocol suite is the TCP/IP suite; its 
foundation is the Internet Protocol (IP). This section will not provide an in depth 
discussion of this protocol, as that is far beyond the scope of this document, consult 
[6] for a detailed introduction. ARPA developed IP over twenty-five years ago under 
the ARPANET project. Today, it has grown in popularity and is the most widely 
implemented standard in use today. Its growth and popularity can be attributed to 
IP’s ability to connect different networks regardless of different physical 
environments, and the flexibility and open nature of the IP network architecture. 

IP is designed for use on large networks; using IP, a connected host anywhere on a 
network can communicate with any other. (In practice, software applications running 
on hosts almost never use raw IP to communicate. Instead, they use one of two 
transport-layer protocols built on top of IP: the Transmission Control Protocol (TCP) 
or the User Datagram Protocol (UDP). Whether applications use TCP or UDP is 
immaterial to routing, which takes place exclusively at the IP layer.) Further, each IP 
host does not need to know a path through the network to every other host. Each host 
only needs to know the address of one or a small number of routers. These routers 
are responsible for ensuring that each IP packet reaches its intended destination. 

In a small network, each router can simply be connected directly to every other 
router. For larger networks, of course, connecting every router to every other would 
be prohibitively expensive. Instead, each router maintains a route table with 
information about how to forward packets to their destination addresses. Correct, 
efficient, and secure operation of any large IP network depends on the integrity of its 
route tables. 
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Route Tables and Routing Protocols 

A router’s primary responsibility is to send a packet of data to the intended 
destination. To accomplish this, each router needs a route table. Each router builds 
its table based on information from the network and from the network administrators. 
The router then uses a set of metrics, depending on the contents of the table and its 
routing algorithm, to compare routes and to determine the ‘best’ path to a destination. 

Routers use four primary mechanisms for building their route tables: 

1. Direct connection: Any LAN segment to which the router is directly 
connected is automatically added to the route table. For example, the 
router Central is connected to the LAN segment 14.2.9.0/24. 

2. Static routing. A network administrator can manually instmct a router to 
use a given route to a particular destination. This method takes 
precedence over any other method of routing. 

3. Dynamic routing. Uses router update messages from other routers to 
create routes. The routing algorithm associated with the particular 
routing protocol determines the optimal path to a particular destinations, 
and updates the route table. This method is the most flexible because it 
can automatically adapt to changes in the network. 

4. Default routing. Uses a manually entered route to a specific ‘gateway of 
last resort’ when route is not known by any other routing mechanism. 
This method is most useful for routers that serve as the sole connection 
between a small LAN and a large network like the Internet. Routers that 
depend on a single default gateway usually do not use routing protocols. 

Although many different dynamic routing protocols exist, this section focuses on 
only two: RIP and OSPF. These two are the most widely used standard routing 
protocols. RIP, the Routing Information Protocol, is an example of a distance vector 
based protocol. OSPF, or Open Shortest Path First, is an example of a link state 
protocol. The table below provides a short comparison. 


Table 4-2-RIP v. OSPF 


RIP 

Distance vector protocol: maintains a list of the distances to other networks 
measured in hops, the number of routers a packet has to traverse in order to 
reach its destination. Limited in scale because any distance greater than 15 hops 
is inaccessible. Broadcasts updates every 30 seconds to all neighboring RIP 
routers to maintain integrity. Each update is a full route table. 

OSPF 

Link state protocol: uses a link speed-based metric to determine paths to other 
networks. Each router maintains a simplified map of the entire network. 

Updates are sent via multicast, and are sent only when the network 
configuration changes. Each update only includes changes to the network. 
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Another important aspect of a routing protocol scheme is the amount of time it takes 
for network architecture or connectivity changes to be reflected in the route tables of 
all affected routers. This is usually called the rate of convergence. In a large 
network, OSPF offers much faster convergence than RIP. 

4.4.1. Common routing hazards 

A question that is often overlooked is “Why do we need to concern ourselves with 
security of the network?” A better question to ask would be “What kind of damage 
could an adversary do to our network?” Section 3 offers some motivations for overall 
router security. This section focuses on security issues related to routing and routing 
protocols. Routing security should be a top priority for network administrators who 
want to: 

■ prevent unauthorized access to resources on the network, 

■ protect mission information from unauthorized access, exposure, and 
modification, and 

■ prevent network failures and interruptions in service. 

An unprotected router or routing domain makes an easy target for any network-savvy 
adversary. For example, an attacker who sends false routing update packets to an 
unprotected router can easily corrupt its route table. By doing this, the attacker can 
re-route network traffic in whichever manner he desires. The key to preventing such 
an attack is to protect the route tables from unauthorized and malicious changes. 
There are two basic approaches available for protecting route table integrity: 

1. Use only static routes - 

This may work in small networks, but is unsuitable for large networks. 

2. Authenticate route table updates - 

By using routing protocols with authentication, network administrators 
can deter attacks based on unauthorized routing changes. Authenticated 
router updates ensure that the update messages came from legitimate 
sources, bogus messages are automatically discarded. 

Another form of attack an adversary might attempt against a router is a denial of 
service attack. This can be accomplished in many different ways. For example, 
preventing router update messages from being sent or received will result in bringing 
down parts of a network. To resist denial of service attacks, and recover from them 
quickly, routers need rapid convergence and backup routes. 

4.4.2. ARP and LANs 

Address Resolution Protocol, or ARP, is the protocol used to map IP addresses to a 
particular MAC or Ethernet address. ARP is described in more detail in RFC 826 and 
Parkhurst [2]. Proxy ARP is a method of routing packets using the Ethernet MAC 
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address instead of the IP address to determine the final destination of a packet. For a 
detailed description of Proxy ARP, consult RFC 1027. 

However, because ARP offers no security, neither does Proxy ARP. The fundamental 
security weakness of ARP is that it was not designed to use any form of 
authentication. Anyone on a LAN segment can modify an entry in the ARP cache of 
a router that serves the segment. Therefore, if a host on the network does not use 
default gateways, but instead uses Proxy ARP to handle the routing, it is susceptible 
to bad or malicious routes. In any case. Proxy ARP is generally not used anymore, 
and it should be disabled. The following example illustrates how to do just that. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# interface ethernetO/0 

Central (config-if)# no ip proxy-arp 

Central(config-if)# exit 

Central(config)# interface ethernetO/1 

Central(config-if)# no ip proxy-arp 

Central(config-if)# end 

Central# 


4.4.3. Routing tables, static routes, and routing protocols 

This section describes how to protect routers from some common routing hazards. 


Router Neighbor Authentication 

The primary purpose of router neighbor authentication is to protect the integrity of a 
routing domain. In this case, authentication occurs when two neighboring routers 
exchange routing information. Authentication ensures that the receiving router 
incorporates into its tables only the route i nf ormation that the tmsted sending router 
really intended to send. It prevents a legitimate router from accepting and then 
employing unauthorized, malicious, or accidental routing updates that would 
compromise the security of a network. Such a compromise might lead to re-routing 
of traffic, a denial of service, or simply giving access to certain packets of data to an 
unauthorized person. 


OSPF Authentication 

OSPF provides authentication to prevent routing attacks. Each router accomplishes 
authentication by the exchange of an authentication key. That is, each router 
connected to the same network segment all use a shared secret key. Each sending 
router then uses this key to sign each OSPE update message. The receiving router 
checks the shared secret to determine whether the message should be accepted. 

OSPE uses two types of neighbor authentication: plaintext and message digest 
(MD5). Plaintext authentication uses a shared secret key known to all the routers on 
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the network segment. When a sending router builds an OSPF packet, it signs the 
packet by placing the key as plaintext in the OSPF header. The receiving router then 
compares the received key against the key in memory. If the keys match, then the 
router accepts the packet. Otherwise, the router rejects the packet. This method does 
not provide much security because the key is in plaintext in the packet. Using this 
method reveals the secret key to any attacker using a network sniffer on the right 
LAN segments. Once an attacker captures the key, they can pose as a trusted router. 

The second, and more secure method, is message digest authentication. The figure 
below shows the example network from Figure 4-1 with its routing protocols. 



Figure 4-3: A Simple OSPF Routing Architecture 


In this example, routers North, East, and Central all share the same secret key, 
rOutes-4-all, with a Key ID of 1. Each of these routers authenticates to each 
other using the MD5 message digest authentication method, whose cryptographic 
authentication type is denoted by a value of 2. Eigure 4-4 shows how East 
authenticates to North. East first builds an OSPE packet, both header and body. It 
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then picks a primary key to use on the network segment. In this case, the key is 
rOutes-4-all, as noted earlier. The corresponding Key ID, 1, is placed in the 
header. The cryptographic authentication algorithm produces a 16-byte result, which 
is also placed in the header. A 32-bit sequence number, generated by East, is placed 
in the header. This sequence number protects against replay attacks so that no two 
OSPF packets will have the same hash value. The sequence number is incremented 
with every new packet. Finally, the secret key is appended to the packet. East then 
mns the cryptographic hash algorithm, MD5, against the OSPF packet. The output of 
the function, or the signature, is written over the secret that was appended to the 
packet. 

The receiving router. North, looks at the Key ID to determine which key was used to 
generate the hash, or signature. The router then uses its own key to regenerate the 
hash on the received packet in the same manner as the sending router. If the 
regenerated hash matches the hash that was sent from East, then the North tmsts the 
packet. Otherwise, it rejects the packet as being invalid. 
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1 
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Figure 4-4: OSPF Calculation of an MD5 Authentication Signature (from [4]) 


OSPF Plaintext Authentication 

This method is not recommended, use the superior MD5 method, below. 
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OSPF MD5 Authentication 

The example below illustrates an example of using MD5 for OSPF router neighbor 
authentication. The example transcripts below show routers North and East receiving 
the key rOutes-4-all. In practice, all the routes connected to a given network 
must be configured in the same way, using the same key. Using the example network 
shown in Figure 4-1, router Central would also have to be configured with MD5 
authentication and the same shared key shown below. 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# router ospf 1 

North(config-router)# network 14.1.0.0 0.0.255.255 area 0 
North(config-router)# area 0 authentication message-digest 

North(config-router)# exit 
North(config)# int ethO/1 

North(config-if)# ip ospf message-digest-key 1 md5 rOutes-4-all 

North(config-if)# end 
North# 

East# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

East(config)# router ospf 1 

East (config-router)# area 0 authentication message-digest 
East(config-router)# network 14.1.0.0 0.0.255.255 area 0 
East(config-router)# network 14.2.6.0 0.0.0.255 area 0 

East(config-router)# exit 
East(config)# int ethO 

East(config-if) # ip ospf message-digest-key 1 md5 rOutes-4-all 

East(config-if)# end 
East# 


RIP Authentication 

The RIP routing protocol also supports authentication to prevent routing attacks. 
rip’s method of authentication is very similar to that of OSPF. In this case, the 
neighboring RIP routers use shared secret keys. Each sending router uses these keys 
to sign each RIP update packet. The receiving router then uses the shared secret to 
check the signature and determine whether the message should be accepted. 

RIP Plaintext Authentication 

This method is not recommended, use the superior MD5 method, below. 

RIP MD5 Authentication 

The example below illustrates an example of using MD5 for RIP router neighbor 
authentication. The example transcripts below show routers from Eigure 4-3, Central 
and South, receiving the key my-supersecret-key, contained in their respective 
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key-chains, CENTRAL-KEYCHAIN and SOUTH-KEYCHAIN. In practice, all the 
routes connected to a given network must be configured in the same way. That is, the 
shared key must exist in both key chains. 

Prior to enabling RIP MD5 authentication, each neighboring router must have a 
shared secret key. RIP manages authentication keys by the use of key chains. A key 
chain is a container that holds multiple keys with the associated key ID’s and key 
lifetimes. Multiple keys with different lifetimes can exist. However, only one 
authentication packet is sent. The router examines the key numbers in order from 
lowest to highest, and uses the first valid key that is encountered. In the example 
below. Central and South have key chains named CENTRAL-KEYCHAIN and 
SOUTH-KEYCHAIN. Both key chains share the keys my-supersecret-key and 
my-othersecret-key. However, both routers will only use the first valid key. 
The other key is usually used when migrating to different keys. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# key chain CENTRAL-KEYCHAIN 

Central(config-keychain)# key 1 

Central(config-keychain-key)# key-string my-supersecret-key 

Central(config-keychain-key)# exit 

Central(config-keychain)# key 2 

Central(config-keychain-key)# key-string my-othersecret-key 

Central(config-keychain-key)# end 

Central# 


South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
South(config)# key chain SOUTH-KEYCHAIN 

South(config-keychain)# key 1 

South(config-keychain-key)# key-string my-supersecret-key 

South(config-keychain-key)# exit 
South(config-keychain)# key 2 

South(config-keychain-key)# key-string my-othersecret-key 

South(config-keychain-key)# end 
South# 

RIP version 1 did not support authentication. This was a feature that was included in 
RIP version 2. Each RIP router must first be configured to use version 2 in order to 
enable authentication during routing updates. The example below shows how to 
enable version 2 of RIP. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# router rip 

Central(config-router)# version 2 

Central(config-router)# network 14.0.0.0 

Central(config-router)# end 

Central# 


Version l.Og 


UNCLASSIFIED 


91 





Router Security Configuration Guide 


UNCLASSIFIED 


South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# router rip 

South(config-router)# version 2 

South(config-router)# network 14.0.0.0 

South (config-router) # end 

South# 

Finally, the example below shows how to enable authentication for RIP. Unlike 
OSPF, authentication for RIP is enabled on the interfaces. In the example below, 
Central will be using the key chain CENTRAL-KEYCHAIN that was created earlier. 
Furthermore, Central will be using the MD5 method of authentication. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# int ethernetO/1 

Central(config-if) # ip rip authentication key-chain 
CENTRAL-KEYCHAIN 

Central(config-if)# ip rip authentication mode md5 

Central (config-if)# end 
Central# 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
South(config)# int ethernetO/0 

South(config-if) # ip rip authentication key-chain SOUTH- 
KEYCHAIN 

South (config-if)# ip rip authentication mode mdS 

South (config-if)# end 
South# 


Key Management 

The strength of both of these methods, RIP and OSPF neighbor authentication, 
depends on two factors: the secrecy of the keys and the quality of the keys. A key’s 
secrecy is intact only if it is known by the trusted routers, but hidden from any 
attacker. The best method for distributing keys to trusted routers is to do it manually. 
The other issue with maintaining secrecy is the question of “How many keys should 
be used in the routing domain?” That is, whether one key should be used for the 
entire routing domain, or a separate key for each router neighbor-to-neighbor 
connection. Using a separate key for each router neighbor-to-neighbor connection 
can become an administrative nightmare, so using a common key for the entire 
routing domain is recommended. However, maintaining the secrecy of the key 
becomes much more important, because failure to do so can compromise the entire 
network. 

The other factor that authentication relies on is the quality of the keys. The rules for 
generating good passwords apply to generating good keys as well. See Section 4.1 for 
a detailed description. 
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Static Routes 

Static routes are manually configured on the router as the only path to a given 
destination. These routes typically take precedence over routes chosen by dynamic 
routing protocols. 

From a security standpoint, static routes are very secure. They are not vulnerable to 
spoofing attacks because they do not deal with router update packets. However, static 
routes are impractical for large networks. Exclusively using static routes will make 
network administration extremely difficult. Furthermore, static routes cannot handle 
events such as router failures. A dynamic routing protocol, however, such as OSPF, 
will re-route traffic in the case of a router failure. 

In most cases, static routes take precedence over their dynamic counterparts. 
However, if an administrative distance is specified, then that static route can be 
overridden by dynamic information. For example, OSPF-derived routes have a 
default administrative distance of 110. Thus a static route must have an 
administrative distance greater than 110 if the OSPF derived route is to have 
precedence over the static route. Static routes have a default administrative distance 
of 1. 

The following example illustrates how to create a static route with a higher 
administrative distance than OSPF. For more information on the internal workings of 
static routes, consult [7]. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# ip route 14.2.6.0 255.255.255.0 14.1.1.20 120 

Central(config)# end 
Central# 


Convergence 

Reducing the convergence time (the time it takes for all routers to learn of a change 
in the network) can improve the level of security. If an attacker creates a spoofed 
route to redirect traffic, then reducing the convergence time will cause that false route 
to die quickly, unless the attacker continues to send routing updates. However, 
constantly sending routing updates will likely expose the identity of the infiltrator. In 
either case, different aspects of network security will be addressed. 

As a cautionary note, reducing convergence time, especially when using RIP, will 
increase network load. The default settings have been selected to provide optimal 
performance. 

The example below illustrates how to reduce convergence on an OSPF and RIP 
network. The timers for OSPF can be viewed by using the show ip ospf pid 
command and the show ip ospf interface interface command. 
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Central# show ip ospf 1 


SPF schedule delay 5 secs. Hold time between two SPFs 10 
secs 


Central# show ip ospf interface ethernetO/0 

EthernetO/0 is up, line protocol is up 

Internet Address 192.168.20.150/24, Area 1 
Transmit Delay is 1 sec. State DROTHER, Priority 1 


Timer intervals configured. Hello 10, Dead 40, Wait 40, 
Retransmit 5 

Hello due in 00:00:05 


The output of the show ip ospf p±d command shows that OSPF on Central will 
perform an SPF (Shortest Path First) calculation 5 seconds after it receives a topology 
change. If this value is 0, then Central starts an SPF calculation after receiving a 
topology change. It will also wait 10 seconds between two consecutive SPF 
calculations. If this value is 0, then two consecutive SPF calculations can be done 
without any waiting period. Reducing both of these timers causes routing to switch to 
an alternate path more quickly in the event of a failure. 

The output of the show ip ospf interface interface command shows that 
the time between Hello packets on interface ethernetO/0 is 10 seconds. The Dead 
interval, which is 40 seconds in the example, is the time hello packets must not have 
been seen before Central declares its neighbor dead. The Retransmit interval is the 
time between LSA (Link State Advertisement packets sent by OSPF) 
retransmissions. This time, which is 5 seconds, must be greater than the expected 
round trip between Central and any other router on the same network. Otherwise, the 
routers will be sending needless LSA packets. The Transmit Delay is the time in 
seconds that Central will take to transmit a link-state update packet. 

If the Hello-interval and Dead-interval are modified on a router, then all other OSPF 
routers on that network must be changed as well. That is, all routers on that network 
must have the same Hello-interval and Dead-interval. 

The example below shows how to modify OSPF timers. The first modification sets 
the SPF calculation delay to 1 second and the delay between two consecutive SPF 
calculations to 4 seconds. The second modification sets the Hello-interval to 5 
seconds, the Dead-interval to 20 seconds, the Retransmit-interval to 8 seconds, and 
the Transmit-delay to 6 seconds. 

Central# config t 

Central (config)# router ospf 1 

Central(config-router)# timers spf 1 4 

Central(config-router)# end 
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Central# show ip ospf 


SPF schedule delay 1 secs. Hold time between two SPFs 4 
secs 


Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# interface ethernetO/0 
Central(config-if)# ip ospf hello-interval 5 
Central(config-if)# ip ospf dead-interval 20 
Central(config-if)# ip ospf retransmit-interval 8 
Central(config-if)# ip ospf transmit-delay 6 
Central(config-if)# end 

Central# show ip ospf interface ethernetO/0 

EthernetO/0 is up, line protocol is up 

Internet Address 192.168.20.150/24, Area 1 
Transmit Delay is 6 sec. State DR, Priority 1 


Timer intervals configured. Hello 5, Dead 20, Wait 20, 
Retransmit 8 

Hello due in 00:00:02 


Similarly, the timers for RIP can be viewed by using the show ip protocols 
command. 

Central# show ip protocols 


Routing Protocol is "rip" 

Sending updates every 30 seconds, next due in 22 seconds 
Invalid after 180 seconds, hold down 180, flushed after 
240 


In it’s current configuration, RIP routing updates are sent every 30 seconds. If no 
update is received within 180 seconds, then the route is declared invalid. The hold 
down time is the time that a route will remain in the routing table before a new route 
is accepted. The flush time is the amount of time that a route will remain in the 
routing table before it is removed if no update to that route is received. The sleep 
time, which is not shown, is the amount of time, measured in milliseconds, an update 
will be delayed before transmission. The example shows how to modify the RIP 
timers. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config) # router rip 
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Central(config-router)# timers basic 20 120 150 230 3 

Central(config-router)# end 
Central# show ip protocols 


Routing Protocol is "rip" 

Sending updates every 20 seconds, next due in 6 seconds 
Invalid after 120 seconds, hold down 150, flushed after 230 


In general, OSPF is preferable to RIP. It is also possible to redistribute OSPF routes 
over RIP, and this is preferable to running RIP on an entire large network. For 
details on this topic, consult [2] Chapter 13. 

4.4.4. Disabling unneeded routing-related services 
Passive Interfaces 

The passive-interface command is used to prevent other routers on the 
network from learning about routes dynamically. It can also be used to keep any 
unnecessary parties from learning about the existence of certain routes or routing 
protocol used. It is typically used when the wildcard specification on the network 
router configuration command configures more interfaces than desirable. The 
example below illustrates such a case. 

Routerl# show config 


interface ethernetO 

ip address 14.1.15.250 255.255.0.0 

I 

interface ethernetl 

ip address 14.2.13.150 255.255.0.0 

I 

interface ethernet2 

ip address 14.3.90.50 255.255.0.0 

I 

router ospf 1 

network 14.0.0.0 0.0.0.255 area 0 
passive-interface ethernet2 


When used on OSPF, this command blocks routing updates from being sent or 
received on an interface. In the example above, OSPF has been enabled to mn on all 
subnets of 14.0.0.0. However, by using the passive-interface ethernet2 
command, OSPF will mn only on interfaces ethernetO and ethernetl. An 
alternative method to this is to simply not enable OSPF on certain interfaces. The 
example below illustrates a configuration that does that. 

Routerl# show config 
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interface ethernetO 

ip address 14.1.15.250 255.255.0.0 

I 

interface ethernetl 

ip address 14.2.13.150 255.255.0.0 

I 

interface ethernet2 

ip address 14.3.90.50 255.255.0.0 

I 

router ospf 1 

network 14.1.0.0 0.0.255.255 area 0 
network 14.2.0.0 0.0.255.255 area 0 


This command functions slightly differently on RIP. When used on RIP, this 
command stops routing updates from being sent out on an interface, but routing 
updates will still be received and processed. This command is especially important 
when using RIP version 1, because that version only uses major network numbers. In 
Figure 4-3, enabling RIP on Central will cause RIP broadcasts to be sent out of 
interfaces ethernetO/0 and ethernetO/1. The reason for this is that both 
interfaces appear to have the same Class A internet address, i.e. M.x.x.x. Thus, 
although ethernet 0 / 0 is part of an OSPF network, RIP broadcasts will be sent 
through that interface. The example below illustrates how to remedy that problem. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config) # router rip 

Central(conflg-router)# passive-interface ethernetO/0 

Central(conflg-router)# end 

Central# 

The syntax for using this command on OSPF is nearly identical. The example below 
illustrates that, however, since OSPF is not enabled on the interface to the RIP 
network, this step is unnecessary. Therefore, the following example is for illustration 
purposes only. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# router ospf 1 

Central(conflg-router)# passive-interface ethernetO/1 

Central(conflg-router)# end 

Central# 


Using filters to block routing updates 

The distribute-list command is used to apply access lists on routing 
protocols. This command has two primary functions. To suppress networks from 
being advertised in updates, the distribute-list out command is used. To 
filter networks received in updates, the distribute-list in command is used. 
Each command behaves differently with respect to the routing protocol used. 
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To apply this command to a routing protocol, access lists must first be created. For 
more information about how to create access lists, see Section 4.3. For illustration 
purposes, an access list with rules filtering out 14.2.10.0/24 will be used. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# access-list 55 deny 14.2.10.0 0.0.0.255 
Central(config)# access-list 55 permit any 

Central(config)# end 
Central# 


The OSPF distribute-list in configuration command prevents routes from 
being inserted into the routing table, but it does not stop routes from being sent out in 
the link-state advertisements (LSAs). Thus all downstream routers will learn about 
the networks that were supposed to be filtered in these LSAs. Some authors, 
including Parkhurst [2], advise against using distribute-list in for OSPF. 

The distribute-list out command in OSPF configuration mode stops routes 
from being advertised in updates. However, this restriction only applies to external 
routes, that is, routes from a different autonomous system (AS). The following 
example shows how to prevent Central from advertising the 14.2.10.0 network from 
the RIP routing domain into the OSPF routing domain. With this setting North and 
East would not see a route to the 14.2.10.0 network. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# router ospf 1 

Central(config-router)# distribute-list 55 out 

Central(config-router)# end 

Central# 


The RIP distribute-list in command deletes routes from incoming RIP 
updates. Subsequently, all updates sent from that router will not advertise the deleted 
route. The following example shows Central deleting the route to 14.2.10.0 network 
as it comes in from a RIP update from South. Therefore, since Central no longer has 
a route to network 14.2.10.0, it will not advertise this network to other routers. Thus, 
North and East will not see a route to 14.2.10.0. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config) # router rip 

Central(config-router)# distribute-list 55 in 

Central(config-router)# end 

Central# 


The RIP distribute-list out command prevents routes from being advertised in 
updates. Thus, the effect of applying the same filter used in the previous examples to 
South is that North, East and Central will not see routes to the 14.2.10.0 network. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
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South(config)# access-list 55 deny 14.2.10.0 0.0.0.255 
South(config)# access-list 55 permit any 

South (config)# router rip 

South(config-router)# distribute-list 55 out 

South(config-router)# end 

South# 


The examples above essentially accomplish the same task, that is, hosts from the 
14.2.10.0 network are prevented from reaching the Internet. However, the three 
different filters also have unusual side effects. Using the first filter, hosts on the 
14.2.10.0 network can communicate with hosts on the 14.1.0.0 network if the hosts 
on the latter network use Central, instead of North, as their default gateway. This is 
because, while Central is not advertising a route to the 14.2.10.0 network, thereby 
preventing North from learning that route. Central still has the route in its table. 

The second and third filter fixes the problem that was evident with the first filter. 
However, a similar problem arises. Connections from hosts on the 14.2.10.0 network 
can be made with hosts on the 14.2.9.0 network if the hosts on the latter network use 
South, instead of Central, as their default gateway. This is because either Central is 
filtering the routes it receives (second filter) or South filters the routes it advertises 
(third filter). In either case. South still maintains a route to the 14.2.10.0 network 
because it is directly connected to it. 

Ultimately, the easiest way to prevent hosts on the 14.2.10.0 network from 
communicating with hosts on any other subnets is to simply turn off interface 
EthernetO/1 on South. 

Migrating from RIP to OSPF: Security issues and concerns 

Although RIP has withstood the test of time and proven itself to be a reliable routing 
protocol, OSPF is the superior routing protocol. Both protocols are supported by 
virtually every routing vendor. Therefore, using either of these routing protocols over 
others such as IS-IS, IGRP, or EIGRP, is recommended. 

However, if using RIP is not an essential requirement, then migrating to OSPF is the 
recommended solution. While both protocols support authentication, OSPF offers 
better convergence times, and using OSPF reduces the likelihood of accidentally 
sending out OSPF packets on an unintended interface. How to migrate is beyond the 
scope of this document, see [2] for detailed directions. However, an important step to 
remember is to remove RIP after OSPF has been enabled. Failure to do so will not 
cause a routing failure, but an attacker could then take advantage of RIP and insert a 
malicious route into the routing table. The following example illustrates how to turn 
off RIP on both example routers. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config)# no router rip 
Central(config)# end 
Central# 
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South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
South (config)# no router rip 
South(config)# end 
South# 


4.4.5. Unicast Reverse-Path Forwarding Verification 

Most Cisco routers running lOS 12.0 and later support a routing-based filtering 
feature called IP unicast reverse-path forward (Unicast RPF) verification. When this 
feature is enabled on an interface, the router uses its routing tables to decide whether 
to accept or drop individual packets arriving on the interface. As noted in Section 4.3, 
it is good security practice to reject a packet with a spoofed source address. Unicast 
reverse-path verification supports rejecting such packets, and in some cases it offers 
significant advantages of using access lists for that purpose. Unicast reverse-path 
verification is not enabled by default; you must explicitly apply it to each interface 
where you want verification to be done. 

How Does Unicast Reverse-Path Verification Work? 

All routers maintain a routing table that lets them decide how to forward packets. 
Unicast reverse-path verification uses the routing table to decide whether a packet 
with a particular source address is valid: if the interface on which the packet with 
address A.B.C.D was received is the one that the router would use to send a packet to 
A.B.C.D, then the packet is considered ‘good’, otherwise it is ‘bad’. Good packets 
are forwarded normally, bad packets are discarded. 

Figure 4-5 shows two packets arriving at the router Central on its ‘inside’ interface, 
EthO/1. The first packet bears a proper source address, it is from a host behind the 
South router. The second packet bears a spoofed source address, it might have been 
generated by a piece of malicious software surreptitiously installed somewhere on 
LAN 2. 

For packet 1, the router looks up its source address, 14.2.10.2, in the routing table. It 
finds the interface Eth 0/1, which is the interface on which packet 1 has arrived. This 
is a match, so the router forwards packet 1 normally out interface Eth 0/0. Eor packet 
2, the router looks up its source address, 7.12.1.20, in the routing table. It finds 
interface Eth 0/0, which is not the interface on which packet 2 has arrived. Because 
the packet has arrived on the wrong interface, it fails unicast reverse-path 
verification, and the router discards the packet. 
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Because unicast RPF verification uses the routing table, it automatically adjusts to 
most to changes in network structure. Access lists, while more broadly applicable, 
also require more maintenance. 


When to Use Unicast Reverse-Path Verification 

This facility can be very useful for rejecting packets with improper IP source 
addresses, but only when the network architecture permits it to be used. You should 
not use unicast RPF verification if any of the following conditions apply. 

■ Router uses asymmetric routes - 

if any of the interfaces on the router participate in asymmetric routes (one 
interface for sending, and a different one for receiving), then unicast RPF 
verification must not be used. It will incorrectly reject packets arriving on 
the receive leg of the asymmetric route. Cisco has stated that future 
versions of lOS will perform unicast RPF correctly in these cases [11]. 

■ Router does not support CEF - 

according to the Cisco documentation, unicast reverse-path verification 
depends on Cisco Express Eorwarding. If your router does not or cannot 
support CEE, then you cannot use unicast RPE. 

Unicast RPE verification is best suited for routers that act as part of the security 
boundary between two networks (e.g. a filtering router between a LAN and the 
Internet). Used properly, it can provide better performance than an access list for 
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ingress and egress filtering. For more details on how and where to apply unicast RPF 
verification, consult [10]. 


Configuring Unicast Reverse-Path Verification 

Unicast RPF verification depends on a particular routing mode called Cisco Express 
Forwarding (CEF). Therefore, to use unicast RPF, first enable CEF, and then enable 
verification on the desired interfaces. The transcript below shows how to enable 
verification on the router Central. 

Central# config t 

Central (config) # ip cef 

Central(config) # interface eth 0/0 

Central(config-if )# ip verify unicast reverse-path 

Central(config-if) # exit 


Some Cisco routers require you to enable CEF with the command ip cef 
distributed instead of the simple version shown above. Consult [10] for details 
about CEF requirements. 

To disable unicast RPF verification, enter interface configuration mode, as shown 
above, and use the command no ip verify unicast reverse-path. 
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4.5. Audit and Management 

4.5.1. Concepts and Mechanisms 

Routers are a critical part of network operations and network security. Careful 
management and diligent audit of router operations can reduce network downtime, 
improve security, and aid in the analysis of suspected security breaches. Cisco 
routers and Cisco lOS are designed to support centralized audit and management. 

This section describes the logging, management, monitoring, and update facilities 
offered in Cisco lOS 11.3 and 12.0. 

■ Logging- 

Cisco routers support both on-board and remote logs. 

■ Time - 

Accurate time is important for good audit and management; Cisco routers 
fully support the standard time synchronization protocol, NTP. 

■ Network Management - 

The standard protocol for distributed management of network component 
is the Simple Network Management Protocol (SNMP). SNMP must be 
disabled or carefully configured for good security. 

■ Network Monitoring - 

Cisco routers support basic facilities for Remote Network Monitoring 
(RMON). The RMON features depend on SNMP, and must also be 
disable or carefully configured. 

■ Software Maintenance - 

Keeping up with new major software releases is important, because new 
releases include fixes for security vulnerabilities. Installing new Cisco 
lOS software in a router is not especially difficult. 

■ Debugging and Diagnostics - 

Troubleshooting router problems requires proficiency with Cisco’s 
diagnostic commands and debugging features. 

The sub-sections below describe recommended configurations for good security. 
Complete details on the commands and features discussed may be found in the Cisco 
lOS documentation, especially the Cisco lOS Configuration Fundamentals Command 
Reference documents for lOS 11.3 and 12.0. 

4.5.2. Configuring Logging and Time Services 

Logging is a critical part of router security; good logs can help you find configuration 
errors, understand past intrusions, troubleshoot service dismptions, and react to 
probes and scans of your network. Cisco routers have the ability to log a great deal 
of their status; this section explains the different logging facilities, describes the 
logging configuration commands, and presents some configuration examples. 
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Keeping the correct time in a router is also important for accurate logs. Cisco routers 
fully support the standard Network Time Protocol (NTP), which is used on the 
Internet and on all major DOD networks to distribute accurate time. Configuration 
guidance for NTP appears at the end of this sub-section. 

Overview and Motivations for Logging 

Cisco routers can log system errors, changes in network and interface status, login 
failures, access list matches, and many more kinds of events. Some motivations for 
keeping router logs are listed below. 

■ Recording router configuration changes and reboots 

■ Recording receipt of traffic that violates access lists (see Section 4.3) 

■ Recording changes in interface and network status 

■ Recording router cryptographic security violations (see Section 5.2) 

There are some events that can be important to security but which Cisco routers 
cannot log. Four such events are: changing EXEC privilege level, changing a 
password, changing the configuration via SNMP, and saving a new configuration to 
the NVRAM. 

Log messages can be directed in five different ways, as discussed below. Messages 
can be sent to all five, or any combination. The most valuable forms of logging are 
forms that are persistent, that can be preserved over time. 

1. Console logging - 

Log messages are sent to the console line (see Section 4.1.2). This form 
of logging is not persistent, messages printed to the console are not 
stored by the router. Console logging is handy for operators when they 
use the console, but are otherwise of little value unless some other device 
or piece of software preserves the output. 

2. Terminal Line logging - 

Any enabled exec session, on any line, can be configured to receive log 
messages. This form of logging is not persistent. Turning on line 
logging is useful only for the operator using that line. 

3. Buffered logging - 

Cisco routers can store log messages in a memory buffer. The buffered 
data is available only from a router exec or enabled exec session, and it is 
cleared when the router boots. This form of logging is useful, but does 
not offer enough long-term protection for the logs. 

4. Syslog logging - 

Cisco routers can send their log messages to a Unix-style syslog service. 
A syslog service simply accepts messages, and stores them in files or 
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prints them according to a simple configuration file. This form of 
logging is the best available for Cisco routers, because it can provide 
protected long-term storage for logs. 

5. SNMP trap logging - 

For some kinds of events, Cisco routers can generate Simple Network 
Management Protocol (SNMP) trap messages. This facility allows 
routers to be monitored as part of an overall SNMP-based network 
management infrastructure. 

Cisco lOS messages are categorized by severity level. The lower the severity level 
number, the more critical the message is. The severity levels are described in the 
table below. Note that, when you are using logging levels in commands in lOS 11.3 
and earlier, you must use the level name; in lOS 12.0 you may use the name or the 
number. 


Table 4-2 - Cisco Log Message Severity Levels 


Level Level Name Description Example 


0 

Emergencies 

Router becoming unusable 

lOS could not load 

1 

Alerts 

Immediate action needed 

Temperature too high 

2 

Critical 

Critical condition 

Unable to allocate memory 

3 

Errors 

Error condition 

Invalid memory size 

4 

Warnings 

Warning condition 

Crypto operation failed 

5 

Notifications 

Normal but important 
event 

Interface changed state, up 
or down 

6 

Informational 

Information message 

Packet denied by access 
list 

7 

Debugging 

Debug message 

Appears only when 
debugging is enabled 


For example, the message below appears in the log when a user changes the mnning 
configuration. It has a severity level of 5, as shown by the numeric field “-5-” in the 
message name. 


Mar 31 9:00:16 EST: %SYS-5-CONFIG_I: Configured from console by vtyO (14.2.9.6) 


Message text 


’-Message name and severity level 

Time that message was generated 

Figure 4-6: Format of a Cisco lOS Log Message 
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For best security, set up both syslog logging and console logging. In a network 
where SNMP management is already deployed, enable SNMP trap logging also. 
SNMP and the related RMON facility are discussed in more detail in the next sub¬ 
section. 

The descriptions below recommend logging configuration settings, for additional 
information about Cisco logging command and facilities, consult the 
“Troubleshooting Commands” section of the Cisco lOS Configuration Fundamentals 
Command Reference. 


Setting up Console and Buffered Logging 

To turn on console logging, use the commands shown below. This example sets the 
logging level for the console to level 5. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z 
Central(config) # ! set console logging to level 5 (notify) 

Central(config) # logging console notification 

Central(config) # logging on 
Central(config) # exit 
Central# 

This example sets the console message level to 5, notifications, which means that 
important messages will appear on the console, but access list log messages will not. 
Use the command logging console info to see all informational messages 
including access list log messages. Use the command logging console debug to 
see ALL messages on the console. 

For buffered and other forms of persistent logs, recording the time and date of the 
logged message is very important. Cisco routers have the ability to timestamp their 
messages, but it must be turned on explicitly. As a rule of thumb, your log buffer 
size should be about 16 Kbytes; if your router has more than 16 Mbytes of RAM, 
then you can set the log size to 32 or 64 Kbytes. The example below shows how to 
turn on buffered logging, how to enable time stamps, and how to view the buffered 
log. 


Central# config t 

Enter configuration commands, one per line. End with CNTL/Z 
Central(config)# ! Set a 16K log buffer at information level 
Central(config)# logging buffered 16000 information 
Central(config)# ! turn on time/date stamps in log messages 
Central(config)# service timestamp log date msec local show-timezo 
Central(config)# exit 
Central# 

Central# show logging 

Syslog logging: enabled (0 messages dropped,! flushes,0 overruns) 
Console logging: level notifications, 328 messages logged 
Buffer logging: level informational, 1 messages logged 
Trap logging: level debugging, 332 message lines logged 
Logging to 14.2.9.6, 302 message lines logged 
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Log Buffer (16000 bytes): 

Mar 28 11:31:22 EST: %SYS-5-CONFIG_I: Configured from console by 
vtyO (14.2.9.6) 


Setting up Terminal Line Logging 

Any terminal or virtual terminal line can act as a log monitor. There are two parts to 
setting up terminal monitor logging. First, set the severity level for terminal line 
monitor log messages; this needs to be done only once. Second, while using a 
particular line, declare it to be a monitor; this needs to be done once per session. The 
example below shows how to set up terminal line monitoring for informational 
severity (level 6) on a telnet session virtual terminal line. 

Central# show users 

Line User Host(s) Idle Location 

*130 vty 0 bob idle 00:00:00 14.2.9.6 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config) # ! set monitor logging level to level 6 
Central(config) # logging monitor information 

Central(config)# exit 

Central# ! make this session receive log messages 
Central# terminal monitor 
Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Central(config) # interface eth 0/1 

Central(config-if)# ! shutdown will log a message, level 5 

Central(config-if)# shutdown 
Central (config-if)# 

Mar 28 15:55:29 EST: %LINK-5-CHANGED: Interface EthernetO/1, 
changed state to administratively down 


Setting up Syslog Logging 

Syslog logging is the most useful form of logging offered by Cisco routers. It offers 
the network administrator the ability to send log messages from all of the routers (and 
other Cisco equipment) on a network to a central host for examination and storage. 
All Unix and Linux operating system configuration include syslog servers, and free 
syslog servers are also available for Windows NT and Windows 2000. * 


The NS A Systems and Network Attack Center offers a suite of Windows NT/2000 tools, called the 
Value Added Tools (VAT). The VAT includes a solid, robust syslog server for Windows NT and 2000. 
It is available free to US Government entities; request a copy from securent@dewnet .ncsc.mil. 
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Review of Syslog Concepts 

A syslog server is a network host that accepts messages and processes them. A 
syslog client is a host that generates messages. The figure below shows a typical 
configuration with syslog in use. 



Figure 4-7: A Small Syslog Configuration 

There are four things that you must set for syslog logging: the destination host or 
hosts, the log severity level, the syslog facility , and the source interface for the 
messages. 

The destination host may be specified with host name, a DNS name, or an IP address. 
Any number of syslog hosts may be specified, but typically only one or two are 
needed (see below). 

The severity level for syslog messages is usually the same as that for buffered log 
messages. Set the severity level limit for messages sent to syslog using the logging 
trap command. 

The syslog facility is simply the name you’ll use to configure storage of your 
messages on the syslog server. There are several dozen valid syslog facility names, 
but the ones used for routers are typically localO through local?. Syslog servers also 
support the notion of severity levels, the levels have the same meanings as the Cisco 
severity levels listed in the table above; for more information consult the 
syslog. conf(8) manual page or other syslog documentation on the server host. 

The source interface is the network connection from which the syslog messages will 
be sent; use the network port on the same network as the syslog server, or the one 
that is the fewest number of network hops distant from the syslog server. 
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The example below shows how to configure the router Central, shown in the figure 
above, to load informational severity and above (level 6) messages to the syslog 
server, using syslog facility local6 and the correct network interface. 

Central# 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# logging trap information 

Central(config)# logging 14.2.9.6 

Central(config)# logging facility local6 

Central(config)# logging source-interface eth 0/1 

Central(config)# exit 

Central# show logging 

Syslog logging: enabled (0 messages dropped, 11 flushes, 0 
overruns) 

Console logging: level notifications, 35 messages logged 
Monitor logging: level debugging, 35 messages logged 
Buffer logging: level informational, 31 messages logged 
Logging to 14.2.9.6, 28 message lines logged 

Log Buffer (16000 bytes): 


Central# 

It is important to configure the syslog server to store router messages in their own 
file. Configuration file syntax for syslog servers is uniform for all Unix and Linux 
syslog servers; the configuration file is almost always /etc/syslog.conf. The example 
below shows the syslog configuration line for saving Central’s messages into a file. 

# Save router messages to routers.log 

local6.debug /var/log/routers.log 

Additional Issues for Syslog Logging 

For a router whose security is critical, such as a border router on the Internet, it is 
best to configure two syslog servers. At least one of the two syslog servers’ logs 
should be backed up to permanent storage (CD-R or tape). 

In cases where a router is protecting an enclave from an outside network (e.g. a 
filtering router connected to the Internet), set up access lists to reject syslog traffic 
from the outside network. Syslog uses UDP port 514. For the example shown in the 
figure above, an access list entry for the router Central could look something like 
this: 


access-list 120 deny udp any 14.2.0.0 0.0.255.255 eq syslog 
For more information on access lists, consult Section 4.3. 

In a situation where a sizable set of routers and other devices are sending messages to 
the same syslog server, separate the devices into 2-5 populations with similar duties. 
Use a separate syslog facility name for each population. For example, local6 for 
boundary filtering routers, locals for internal routers, and local4 for internal switches 
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and other network hardware. Save all messages of critical (level 2) severity and 
above to a single special file, and otherwise save messages for each facility into a 
separate file. The syslog configuration lines below illustrate this. 

# Critical and higher messages to critical.log 

locals.crit /var/log/critical.log 

locals.crit /var/log/critical.log 

local4.crit /var/log/critical.log 

# All other router and switch messages to their respective files 

locals.debug /var/log/border-routers.log 

locals.debug /var/log/inner-routers.log 

local!.debug /var/log/other-hw.log 

SNMP Trap Logging 

Cisco routers have the ability to report certain events as SNMP traps. While only a 
small subset of all log messages can be reported this way, it can be useful in a 
network that already has SNMP management deployed. 

There are four parts to setting up SNMP trap logging. First, set the trap logging 
level, second, select an SNMP logging host, third, set the SNMP source interface, 
last, enable SNMP traps for syslog logging. The example below shows how to 
configure SNMP trap logging for a receiving host 14.2.9.1. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# logging trap information 

Central (config)# snmp-server host 14.2.9.1 traps public 

Central(config)# snmp-server trap-source ethernet 0/1 

Central(config)# snmp-server enable traps syslog 

Central(config)# exit 

Central# 

Many of the trap messages sent by a Cisco router will not appear as formatted error 
messages in commercial SNMP viewing tools. It may be necessary to add Cisco- 
specific format specifications to the SNMP tools. However, trap messages about link 
status changes and other typical network hardware events should be interpretable by 
commercial SNMP tools, and may be useful in monitoring the network status. SNMP 
is described in more detail in the next sub-section. 


Time Services, Network Time Synchronization and NTP 

Successful audit of a large network can depend on synchronization of the various 
logs and records maintained for the hosts on that network. All Cisco routers have a 
clock that maintains the time and date, although some older Cisco models lose time 
when they are turned off. It is very important to set the time on a router when it is 
first installed, and then keep the time synchronized when the router is in operational 
use. 
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It is possible to perform manual network time synchronization, adjusting the time on 
each router and host on a network manually on a regular basis. Manual time 
synchronization is tedious, error prone, and unreliable. Cisco routers fully support 
automated network time synchronization based on the standard Network Time 
Protocol (NTP). The sub-sections below give some background information on NTP, 
and explain how to configure it on Cisco routers. 


Setting the Time Manually 

To set the time, follow these three steps: first, check the clock, second, set the 
timezone if necessary, and last set the time. Examine the clock using the show 
clock detail command. If the timezone is not correct, then set the time zone 
using the clock timezone configuration command. If the detail output reports a 
time source of NTP, then do not set the clock manually, see the descriptions of NTP 
below. Otherwise, set the time in privileged EXEC mode by using the clock set 
command, and turn off NTP on each interface using ntp disable. 

Central# 

Central# show clock detail 

22:26:21.747 UTC Tue Mar 28 2000 
Time source is user configuration 
Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# clock timezone EST -5 

Central(config)# interface eth 0/0 
Central(config-if)# ntp disable 
Central(config-if)# end 

Central# clock set 17:27:30 28 March 2000 
Central# show clock 

17:27:34.495 EST Tue Mar 28 2000 

Review of NTP Concepts 


NTP is the standard Internet protocol for 
time synchronization, and it is used on 
most large operational networks. Typical 
NTP deployment is hierarchical, as shown 
at right: one or more ‘stratum 1’ servers 
get theh time from an authoritative 
source, like an atomic clock. Stratum 2 
hosts get their time from stratum 1 
servers, and so on. NTP is designed to 
make time synchronization automatic and 
efficient. Because having accurate time 
can be important for security, especially 
for intmsion and forensic analysis, NTP 
should be used whenever it is available. 
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If an NTP client is configured with several NTP servers, it will select among them 
automatically based on time accuracy and stratum level. Cisco routers (except the 
old 1000-series) are capable of acting at any stratum in the NTP hierarchy except 
stratum 1. As shown in the diagram, NTP clients may also have peer associations; 
setting up peer associations is beyond the scope of this guide. For more information 
about NTP configuration, consult the “Performing Basic System Management” 
chapter of the Cisco lOS Configuration Fundamentals Configuration Guide. 

In some cases, a Cisco router may be used as the boundary router between the 
Internet and an internal, protected network, and the network requires time 
synchronization from a time server on the Internet. In these cases, the router should 
be configured as an NTP client to the desired Internet time server(s), and should 
serve as the NTP server to the hosts on the internal network. This configuration will 
allow the router to block general NTP traffic at the boundary. If at all possible, NTP 
authentication should also be used (see below). 

Commercial stratum 1 radio receivers are available that use a broadcast time source 
(e.g. the time signal from the US Naval Observatory) to offer NTP service. If your 
network has one of these, then you can configure all your routers can go get their 
time from it, directly or indirectly. 

Configuring Basic NTP Service 

To set up a Cisco router to participate in an NTP network, simply designate one or 
more NTP servers. To find out the main NTP servers on the wide-area network you 
plan to join, consult the network administrator. 

There are two steps to configuring a Cisco router to be a simple NTP client: first, set 
the NTP source interface, second, designate one or more NTP servers. The NTP 
source interface is the network connection from which the NTP control messages will 
be sent; use the network interface on the same network as the designated server, or 
the one that is the fewest number of network hops distant from the servers. To add 
an NTP server use the ntp server command with the source qualifier. The 
example below shows how to configure the router South to use the router Central as 
its NTP server, and how to check that the NTP association is working. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# interface ethO/0 

South(config-if)# ntp enable 
South(config-if)# exit 

South(config)# ntp server 14.2.9.250 source ethO/0 

South(config)# exit 

South# ! wait twenty seconds or so.. 

South# show ntp associations 

address ref clock st when poll reach delay offset 

*-14.2.9.250 26.15.203.9 9 11 512 377 2.0 -0.25 

* master (synced), # master (unsynced), + selected, - candidate, 
-configured 
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South# show clock detail 

09:30:08.170 EST Wed Mar 29 2000 
Time source is NTP 

Summer time starts 02:00:00 EST Sun Apr 2 2000 
Summer time ends 02:00:00 EOT Sun Oct 29 2000 
South# 

Access restrictions can be imposed on NTP in two ways: interface access lists and 
NTP access lists. Interface access lists should be configured to permit NTP protocol 
(TCP port 123 and UDP port 123) only for designated NTP servers. Access list 
entries to permit NTP traffic with a designated address 14.2.9.250 are shown below. 
For more information about access lists consult Section 4.3. 

access-list 120 permit tcp 14.2.9.250 eq ntp 14.2.9.64 eq ntp 
access-list 120 permit udp 14.2.9.250 eq ntp 14.2.9.64 eq ntp 

NTP access lists can be used to impose fine-grained access control on NTP servers, 
clients, and peers. A full explanation of NTP access control is outside the scope of 
this guide, check the Cisco lOS documentation for details. The example below 
shows how to set up an NTP server, and restrict NTP transactions to that server 
alone. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config) # ntp server 14.2.9.250 source ethernet 0/0 

South(config) # access-list 21 permit host 14.2.9.250 

South(config )# access-list 21 deny any 

South(config) # ntp access-group peer 21 

South(config) # exit 

South# show ntp associations 

address ref clock st when poll reach delay offset 

*-14.2.9.250 26.15.203.9 9 11 512 377 2.0 -0.25 

* master (synced), # master (unsynced), + selected, - candidate, 
-configured 


By default, a Cisco router configured with one or more NTP servers or peers will act 
as an NTP server. Unless your network is responsible for providing time service to 
other networks, you should disable NTP on all external interfaces. The example 
below shows how to disable NTP server facilities on an interface. 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# interface eth 0/2 

Central (config-if)# ntp disable 

Central(config-if)# end 

Central# 


Configuring NTP Authentication 

Cisco lOS supports authenticated NTP, which uses pre-placed keys to establish a 
tmsted community of NTP servers and peers. Setting up such a community is outside 


114 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED Implementing Security on Cisco Routers 


the scope of this guide; the description below shows how to set up authentication for 
an Cisco router so that it can use a designated NTP server that uses authentication. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# ntp authenticate 

South(config)# ntp authentication-key 1 mdS router 
South(config)# ntp trusted-key 1 

South(config)# ntp server 14.2.9.250 key 1 source ethernet 0/0 

South(config)# exit 

Configuration Sample 

The configuration command listing below shows the configuration commands for a 
router with console logging, buffered logging, syslog logging, and authenticated 
network time synchronization. The host receiving the log messages is 14.2.9.6, and 
the time server is 14.2.9.250. This sample is formatted as it would appear in a 
configuration text file stored on a host for download to the router South. 

! turn on timestamps for log entries 

service timestamps log datetime msec localtime show-timezone 

! setting logging levels and syslog parameters 

logging console notifications 

logging monitor debug 

logging buffered 16000 informational 

logging facility local6 

logging source-interface Ethernet 0/1 

logging 14.2.9.6 

logging on 

! a tiny access list to permit access only for Central 
access-list 21 permit 14.2.9.250 
access-list 21 deny any 

! designate Central as our sole NTP server with authentication 

ntp authentication-key 1 md5 071D2E595A0C0B 7 

ntp authenticate 

ntp trusted-key 1 

ntp clock-period 17180154 

ntp access-group peer 21 

ntp server 14.2.9.250 key 1 source EthernetO/0 


4.5.3. Security for the Simple Network Management Protocol (SNMP) 

Overview 

The Simple Network Management Protocol (SNMP) supports a connection between 
two entities that communicate with each other: the manager and the managed entity, 
the agent. In the case of Cisco routers, the router is always the agent. A software 
application on a PC or workstation normally acts as the manager. A good source for a 
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freeware implementation of an SNMP agent may be found at the UC Davis SNMP 
home page (http: / /ucd-snmp. ucdavis . edu - the source for the SNMPv3 agent 
used in the creation of this section of the guide). 

An SNMP agent device maintains information accessible; the information on each 
device is organized in a virtual store called a Management Information Base (MIB). 
SNMP is the transport protocol used to share and change information between MIBs. 

A MIB is a hierarchical, tree-like stmcture used to store a virtual database of network 
management information. Each piece of data, or object, in a MIB is referenced by an 
object identifier (OID). An OID is a unique, dotted, numerical name, where the dots 
separate branches in a MIB tree. When requesting the value of an object, one may use 
the OID or the actual name of each branch (separated by dots). If the referenced 
value is not a bottom leaf of the tree, values for the entire branch are returned. An in 
depth discussion of SNMP data organization is outside the scope of this guide; for 
more information consult [6]. 

SNMP may be used to query the status of or set the values of network components. 
SNMP may also be used by an entity on the network to send alerts indicating 
problems. There are currently three versions of SNMP: SNMPvl, SNMPv2c and 
SNMPv3. lOS version 11.3 supports SNMPvl and SNMPv2c. lOS version 12.0 
supports all three versions of SNMP. 

This section will give a brief overview of SNMP security and will detail how to 
enable SNMP more securely. Cisco lOS supports a large number of SNMP -related 
commands, those that do not have a direct impact on security are not covered. 

SNMP Security 

When SNMPvl was developed, it was originally intended to be a short-term solution 
for (remotely) managing networks. As such, it was developed quickly and strong 
security was not a requirement. However, since it was the only network management 
protocol available at the time, it became widely used. Proposals were put forth to 
integrate security (as well as more functionality) into later versions of the protocol. 
Unfortunately, conflict arose between competing proposal advocates and no security 
standard was agreed upon. Consequently strong security was left out of SNMPv2c. In 
the late 1990s, SNMPv3 was developed. It was designed specifically with strong 
security in mind. 

SNMPvl and SNMPv2c have weak security. SNMPvl uses a community string to 
limit access to the MIB. This string is sent across the network in clear text. SNMPv2 
relies on the same mechanism for access control to the MIB. SNMPv3 defines three 
levels of security. They are described in the table below. 
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Table 4-5: SNMPv3 Security 



Security Level 

Authentication 

Encryption 

SNMPv3 

noAuthNoPriv 

Username sent in the clear 

None 


authNoPriv 

HMAC-MD5 or HMAC-SHA 

None 


authPriv 

HMAC-MD5 or HMAC-SHA 

DBS (56-bit) 


The Cisco documentation indicates that lOS 12.0 supports all three security levels. 
However, DBS 56-bit encryption was not supported in the versions of lOS used for 
preparation of this section (12.0(7) and 12.0(5)). 


Configuring SNMP - Getting Started 

In both lOS versions 11 and 12, there are some basic commands you must mn to 
enable SNMP. By default, SNMP is not turned on in the router. In order to enable 
SNMP a default community string must be set. This string is stored on the router in 
clear text and will be sent across the network in the clear. So, anybody who knows 
this community string has access to essentially the entire MIB. SNMP logging must 
also be enabled (see section 4.5.1). It is a good idea to mn the show snmp command 
to display the SNMP status and statistics, as shown below. 

East# config t 

Enter configuration commands, one per line. End with CNTL/Z 
East(config)# snmp-server community publicstring 
East(config)# snmp-server host 14.2.6.6 traps public 

East(config)# exit 
East# show snmp 
Chassis: east 
Contact: John Doe 
Location: Headquarters 
0 SNMP packets input 

0 Bad SNMP version errors 
0 Unknown community name 

0 Illegal operation for community name supplied 
0 Encoding errors 
0 Number of requested variables 
0 Number of altered variables 
0 Get-request PDUs 
0 Get-next PDUs 
0 Set-request PDUs 
0 SNMP packets output 

0 Too big errors (Maximum packet size 2048) 

0 No such name errors 
0 Bad values errors 
0 General errors 
0 Response PDUs 
0 Trap PDUs 
SNMP logging: enabled 

Logging to 14.2.6.6.162, 0/10, 0 sent, 0 dropped. 

East# 
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Running these basic commands by themselves is not very secure. Unfortunately, on 
Cisco lOS version 11.3 (which implements SNMPvl and SNMPv2c), there is no 
other alternative when enabling SNMP. While there is some mention of enhanced 
security options (to support SNMPv2c) mentioned in Cisco documentation, these 
commands have been disabled. However, in version 12.07, SNMPv3 has been 
implemented and provides more security features. The rest of this section focuses on 
SNMPv3. 

SNMPv3 

A Cisco router capable of mnning SNMPv3 allows for more security measures to be 
applied. It is a good idea to disable the public community string. Then an access-list 
(see Section 4.3) needs to be created to limit machine access to the router (through 
SNMP). More than one machine may be added on the access-list. Following is an 
example that does this. 

East# config t 

Enter configuration commands, one per line. End with CNTL/Z 
East(config) # no snmp-server community publicstring 
East(config) # access-list 20 permit 14.2.6.6 

East(config) # exit 
East (config)# 


After these commands, SNMP is still enabled but no one has access to the MIB 
because the community string, which solely defined access to the MIB, is disabled. A 
better method to allow access to the MIB is to use strict controls. Limited access may 
be given to the MIB by defining groups, users and MIB views. A MIB view defines a 
portion of the MIB that a user or group may see/modify provided they have the 
appropriate credentials. First, a group must be defined by specifying a group name, 
the version of SNMP and the security model desired. A specific SNMP MIB view, as 
well as the access to that view may also be defined. If this MIB view is not specified 
the default is to have access to basically the whole MIB. The second step is to add 
users to the group. Then a MIB view should be defined to either include specific MIB 
branches or exclude specific MIB branches. 

The following example defines a non-privileged user, “jdoe”, who is a member of the 
“publicUser” group. This group has read access to the “sysonly” view, which is the 
“system” branch of the MIB. This branch contains useful information and is 
beneficial for users to have access to. No community string is required; instead 
authentication is based on the user name. This is an example of a noAuthNoPriv 
security model. The following example also introduces two new commands used to 
verify that the new groups and users have been added correctly. 

East# config t 

Enter configuration commands, one per line. End with CNTL/Z 
East(config) # snmp-server group publicUser v3 noauth read 
sysonly 

East(config) # snmp-server user jdoe publicUser v3 
East(config) # snmp-server view sysonly system included 
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East(config)# exit 
East# 

East# show snmp group 

groupname: publicUser security model:v3 noauth 

readview :sysonly writeview: <no writeview specified> 

notifyview: <no notifyview specified> 

row status: active 

East# 

East# show snmp user 

User name: sysuser 

Engine ID: 00000009020000500F033680 
storage-type: nonvolatile active 
East# 

East# show snmp view 

sysonly system - included nonvolatile active 
East# 


The more secure model implemented is authNoPriv. This security model uses MD5 
or SHA to hash the community string. The steps to support this security model are 
similar to the steps in supporting the noAuthNoPriv model. First, a group must be 
defined. Then users must be added to the group with a password string. This string 
may be hashed using MD5 or SHA. Then the MIB view is defined. A MIB view may 
be defined by more than one included/excluded statement to restrict the view to the 
appropriate MIB branches. 

The following example defines a privileged user, “root” who uses MD5 for 
authentication. This means that when user “root” tries to access/modify MIB data, his 
community string “secret” will be hashed and then sent across the network. This 
makes it hard to compromise the community string. User “root” is a member of the 
“administrator” group. In this example, members of the administrator group have 
restricted read and write access, defined by the view “adminview”, to the MIB. This 
view gives access to all parts of the MIB except the branches that display routing 
information. So, even if the community string is somehow compromised, the routing 
tables are not accessible remotely. Likewise, the routing tables are not permitted to be 
modified remotely. Of course, while not shown, it is always a good idea to use the 
show commands to verify the new settings. 

East# config t 

Enter configuration commands, one per line. End with CNTL/Z 
East(config)# snmp-server group administrator v3 auth read 
adminview write adminview 

East(config) # snmp-server user root administrator v3 auth mdS 
"secret" access 20 

East(config) # snmp-server view adminview internet included 
East(config)# snmp-server view adminview ip.ipAddrTable excl 
East(config)# snmp-server view adminview ip.ipRouteTable excl 

East(config)# exit 


The examples above showed some basic rules that should be followed when 
configuring SNMP on a router. Access-lists, users, groups and views must be defined 
to control access to the MIB. While SNMP is helpful because it allows an 
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administrator to remotely configure the router, it also provides a conduit into a 
network. 

4.5.4. Security for Remote Monitoring (RMON) 

This sub-section describes RMON and security issues related to it. If you are not 
using RMON, it should be disabled; because RMON is a high-level facility based on 
SNMP, RMON can be disabled simply by disabling SNMP (see Section 4.2). 
Otherwise, follow the guidance below. 

Overview of RMON 

Remote Monitoring (RMON), is an extension of SNMP. It provides the capability 
of monitoring and analyzing traffic - data to and from network devices on distributed 
network segments. The RMON standard was originally developed by the Internet 
Engineering Task Force (IETF) to provide proactive monitoring and analysis of 
traffic data on distributed LAN segments. The RMON Management Information 
Base (MIB) defined in RFC 1757 is a standard method for monitoring basic 
operations of network devic es on LAN segments by providing interoperability 
between SNMP management stations and RMON monitoring agents. Protocol 
analyzers or RMON probes add enhanced monitoring capability of RMON agents by 
passively collecting data packets on the monitored LAN segment. The probe 
communicates the data collected to a Network Management Station via SNMP. On 
the network management station, a network administrator uses applications such as 
NetScout Manager Plus, Optivity LAN, or HP OpenView to process and display the 
RMON results in graphical or report form. 

RMON specifications are defined in the basic RMON standard, RFC 1757, referred 
to as RMONl and in the extended version, RFC 2021, referred to as RMON2. 
RMONl is widely implemented in most data communication devices. However, 
RMON 1 collects current and historical traffic statistics up to the MAC-layer of the 
OSI model. RMON2 provides traffic -level statistics plus finer granularity of network 
behavior from the network to the application layers of the OSI model. 

Implementation of RMON in Cisco Routers 

The Cisco lOS versions installed in most Cisco routers, beginning with lOS 11.1 on 
up to lOS 12.0, implement a small sub-section of the RMONl agent standard. lOS 
images ordered with the explicit RMON option, basically RMONl, collect and log 
information in all nine groups. Statistics, History, Alarm, Host, HostTopN, Matrix, 
Filters, Packet Capture, and the Event Groups. If the agent installed on the router 
does not include the explicit RMON option, the RMON agent implements the Alarm 
and Event groups only. Since the RMON option is an add-on enhancement to the 
Cisco router’s lOS, this document covers only those features and security concerns 
applicable to the most common lOS. 
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In order to enable RMON on the Cisco routers, a Read Only community string is 
required when configuring the standard SNMP agent. As a security precaution, a 
read/write community string is highly discouraged (see Section 4.2). Some network 
monitoring probes may require a read/write community string in order to 
communicate with the agent. In addition, if the network architecture includes a 
deployed SNMP infrastructure and network management station, then enable SNMP 
traps on the router (see Section 4.5.2). The network management station will record 
details about all configured events triggered on the monitored router. 

The basic lOS RMON agent supports the Alarm and Event groups. The configuration 
of the alarm group is dependent on a previously configured RMON event. The alarm 
group periodically samples statistics from variables and compares them to thresholds 
configured on the agent. The configured parameters of an alarm identify a SNMP 
MIB variable to monitor, the polling period, a rising threshold with the associated 
event, and a falling threshold. If a data sample crosses a defined threshold, the 
RMON agent fires an event. The event fired, logs a message or generates a trap and 
transmits it to the Network Management station. The implementation of the rising 
and the falling thresholds of an alarm are dependent on the previous configuration of 
an associated event. The basic lOS RMON agent supports the following RMON 
commands: 

show rmon alarms Display information on alarms configured 

show rmon events Display information on events configured 

rmon event number [log] Configure an RMON event 

[trap community] 

[description string] 

[owner string] 


rmon alarm number MIB-object Configure an RMON alarm 

Interval {delta | absolute} 
rising-threshold value [event-number] 
falling-threshold value [event-number] 

[owner string] 

The first two commands display information on configured RMON facilities. Use 
the rmon event command to provide a description of an event and specifies 
whether a message is logged or a trap is generated. Use the rmon alarm command 
to designate the actual MIB variable monitored on the Cisco router. RMON alarms 
provide an excellent tool for monitoring the network interfaces supported by the 
router. However, there are several limitations on the type of SNMP variables RMON 
is capable of monitoring. Alarms may define any SNMP MIB variable that has an 
elementary data type such as integer, counter, gauge, timeticks, etc. The MIB object 
monitored must also resolve to an ASN.l notation. It is acceptable to use the Object 
Identifier (ODD) or the qualified variable name that resolves to its OID. An important 
requirement that is easily overlooked is the instance number of the monitored 
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variable. All monitored objects must include an instance number of the monitored 
variable. Variables included in the SNMP table format will have an instance number 
equivalent to the entry number of the table. All other elementary data variables 
should have an instance number of ‘O’. For example, the following command defines 
an alarm configured on a member of the MIB II interfaces table, iff able: 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# rmon alarm 1 ifEntry.13.1 30 delta 

rising-threshold 40 1 falling-threshold 0 owner rscg 

Central(config)# exit 

Central# show rmon alarms 

Alarm 1 is active, owned by rscg 
Monitors ifEntry.13.1 every 30 second(s) 

Taking delta samples, last value was 3 
Rising threshold is 40, assigned to event 1 
Falling threshold is 0, assigned to event 0 
On startup enable rising or falling alarm 

Alarm 2 is active, owned by config 


Central# 

The interface entry, if Entry .13.1, identifies variable ifInDiscards, the number of 
inbound packets discarded. Alarm number 1 defines a sampling period of every 30 
seconds for the number of discarded packets inbound to the Ethernet interface stored 
at table entry 1 or instance 1. The agent monitors increases of forty discarded 
packets or more starting from the last value sampled. 

A router’s RMON agent can be very useful for monitoring the number of checksum, 
input and output errors, input and output discarded packets, unknown or unsupported 
protocols, etc. RMON may be very data intensive depending on the number of 
monitored variables and the length of the sampling period. If the amount of traffic 
generated by RMON seems to be too high, then change the sampling period to a 
longer time (e.g. 30 seconds to 60 seconds). 


4.5.5. Performing Cisco lOS Software Updates 

This sub-section outlines the motivations and procedures for upgrading the system 
software on a Cisco router. An upgrade can be beneficial for security, but if done 
improperly it can leave a router vulnerable. It is important to note that most Cisco 
updates can only be accomplished by replacing the lOS software mnning on the 
router; there is no facility for amending or patching installed lOS software. This 
section also presents i nf ormation about backing out of an upgrade. 

To determine the current software release mnning on a router, use the command 
show version, and identify the version and memory size as shown in the transcript 
below. 
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Central> show version 

lOS(tm) 3600 Software (C3640-I-M), Version 11,3 (4)Tl , RELEASE (fcl) 
Copyright (c) 1986-1998 by cisco Systems, Inc. 


System image file is "flash:c3640-i-mz.113-4.Tl", booted via flash 
cisco 3640 (R4700) processor with 28672K/4096K bytes of memory . 

8192K bytes of processor board System flash (Read/Write) 


Central> 

The underlined portions of the transcript are the software version, router model, 

RAM size, and flash memory size, respectively. To compute the total RAM on the 
router, simply add the two parts of the RAM size rating: this router has 32MB of 
RAM. It is important to know the router model and memory sizes before attempting 
to obtain a software upgrade. 

Motivations for Updating Router Software 

Installing an lOS update entails inconvenience and the risk of disruption of service. 
Weigh the benefits of upgrading against the risks before you start. The list below 
describes some good reasons for installing an update. 

1. To fix known vulnerabilities - 

when security vulnerabilities are found in Cisco lOS products, one 
solution may be to upgrade to a later edition of the lOS software. 

2. To support new features - 

Cisco has added new operational and security features to each new lOS 
release. If you need one or more of these features to support your 
network, or to enforce your local security policy, then it makes sense to 
upgrade. 

3. To improve performance - 

you might need an upgrade to support new hardware or hardware 
features. If the performance benefit is greater than the cost of upgrading, 
then do the upgrade. 

Software updates entail substantial costs. First, the router must be out of service for 
at least a short time during the installation process; depending on router model and 
other factors, the minimum downtime will range from about a minute to several 
minutes. Second, some features may not work in a newer release; they might be 
broken or simply unsupported. It is very important to read the release notes for a new 
release carefully before installing it, to ensure that the new software can fully support 
the router functions your network needs. Third, a new release may degrade 
performance, either by implementing new features or by reducing available free 
memory. If the performance of your router is critical, then measure the performance 
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before upgrading, and again afterwards; be prepared to back out if the performance 
has suffered. 

Deciding which update to pick is a complex topic, you must take many factors into 
account: feature availability, release status, cost, router memory size, and bug history. 
For more information about Cisco lOS release types, see Section 8.3. 

Obtaining Updates 

Cisco makes software updates available through a variety of purchase and 
maintenance mechanisms. The logistics of purchasing updates is beyond the scope of 
this document. If you have a maintenance agreement with Cisco, you can download 
updates from the Software Center on the Cisco web site. 

Whenever you download Cisco lOS software, it is best to check the length after 
downloading. During the software selection and download sequence at Cisco’s web 
site, you will be given the length of the release in bytes. Print the summary web 
page, which will include the length, for the lOS version you’ve selected for your 
upgrade. After downloading the lOS binary file, check the length against the printed 
page; if they differ, discard the file and download it again. 

Before You Perform the Update 

Follow the checklist below before installing a new version of Cisco lOS on your 
router. 

1. Ensure that you have enough memory. 

Cisco routers have two fundamental kinds of memory: RAM and Hash. 
Every Cisco lOS release has minimum memory requirements. Use the 
commands show version and show flash to check the amount of 
memory your router has. Do not install an update unless the router to be 
upgraded satisfies the memory requirements for both RAM and Elash. 
(Often, a major upgrade will require more memory, because Cisco 
typically sells routers with just enough memory to mn the lOS version 
pre-installed at purchase.) 

2. Check your TFTP, RCP, or FTP configuration. 

Router software updates are normally performed using TFTP or Unix 
RCP; Cisco lOS 12.0 supports FTP. Make sure that the TFTP, RCP, or 
FTP server is correctly set up for both upload and download. Copy the 
new Cisco lOS software into the server’s download directory. 

If possible, use FTP for performing Cisco upgrades. (If the router to be 
upgraded is mnning lOS 11.3 or earlier, then FTP will probably not be 
available.) While TFTP is supported by all lOS versions, it is not a 
secure service, and normally should not be mnning on any host in a 
secure network. Enable TETP only for the update sequence, then disable 
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it again. If possible, connect the TFTP server host to your router 
through a separate network connection, not through your operational 
network. RCP is a little more secure and more reliable than TFTP, but is 
not supported on all Cisco routers nor it is generally available except on 
Unix platforms. 

3. Schedule your downtime. 

Installing an update imposes a minimum downtime, and may impose 
much longer downtime (up to half an hour if things go wrong and you 
have to back out). Schedule your upgrade ahead of time, and i nf orm the 
user community as needed. 

4. Read the enthe upgrade procedure, below. 

Review the entire procedure before you start. Be sure that you are 
familiar with all the lOS commands involved. 

If possible, it is safest to replace a router and take it offline for update. If a redundant 
router or a hot spare is available, take advantage of that to perform the update without 
dismpting service. 

Update Procedure 

This section presents a suggested sequence of steps for installing Cisco lOS software. 
The sequence is very conservative, by following it you can be sure to avoid mishaps, 
and ensure that you can restore your previous lOS version if necessary. The 
sequence has three phases: backup, install, and test. The backup phase, steps 1-3, 
involves copying the mnning lOS software and configuration onto the TFTP server 
host for safekeeping. The install phase, step 4, involves loading the new software. 
The test phase, step 5-6, involves checking that the new software is mnning the old 
configuration successfully. The steps are described below, followed by a console 
hanscript of a successful update. 

0. Log in on the router console, confirm the current lOS and boot version. 

It is best to perform router updates from the system console rather than 
from a network login. The console will show important status messages 
in the later steps of the installation that would not be visible otherwise. 
Check the current lOS version number and the name of the router’s boot 
image with the commands show version and show flash, make a 
record of them. 

1. Enable privileges, and back up the current lOS software. 

Copy the current lOS release to the server using the copy command as 
shown below. 

Central# copy flash tftp 

You must supply the IP address or host name of the TFTP server 
host. If this step fails, do not proceed, abandon the update and 
check the server configuration before trying again. 
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2. Shut down external interfaces. 

If the router to be upgraded is used to enforce security at an enclave 
boundary, such as the boundary between your network and the Internet, 
then disable the outside network interfaces using the shutdown 
command in interface configuration mode. 

Central# config t 

Central (config)# interface eth 0/0 
Central(config-if)# shutdown 
Central(config-if)# end 

3. Back up the current mnning configuration. 

Copy your current running configuration to your TFTP server using the 
copy command. (Note: make sure you have followed the password 
handling instmctions in Section 4.1 before doing this.) 

Central# copy running-config tftp 

You must supply the IP address or host name of the TFTP server host. If 
this step fails, do not proceed, abandon the update and check your TFTP 
configuration before trying again. 

4. Load the new software. 

Copy the new lOS software from the TFTP or FTP server to the flash 
memory of the router. On most Cisco routers, the flash will be erased 
automatically during this step; if asked whether to erase the flash, answer 
yes. Use the copy command as follows. 

Central# copy tftp flash 

On some Cisco routers, it is possible to store several lOS releases in flash 
memory and select which one to mn. (Because very few Cisco routers 
have sufficient flash memory to hold multiple lOS releases, that scenario 
is not covered here.) If this copy succeeds, your router may 
automatically reboot; if it does not, then reboot it manually using the 
command reload. If you are performing the update over a network 
connection, your connection will be broken at this point. 

Central# reload 

Proceed with reload? [confirm] y 

5. Confirm the new lOS version and boot image. 

Watch the boot messages on the router console to confirm the new lOS 
software version and boot image. If you performed steps 1 through 4 
over a network connection, re-establish the connection at this point and 
check the lOS version and boot image with show version. Then, 
enable privileges and confirm the configuration status with show 
running-conf ig. Check the Status of the interfaces, and check that the 
access lists and static routes are still present. 

Central# show version 

Cisco Internetwork Operating System Software 
lOS(tm) 1600 Software (C1600-SY56I-M), Version 
12.0(9), RELEASE SOFTWARE 
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Central# show ip interface 
Central# show running-config 


6. Bring up external interfaces, if necessary. 

If you shut down your router’s external interfaces in step 2, they should 
have come back up as part of the reload in step 4. If the second 
command in step 5 showed that they did not come back up, then bring 
them back up now using the command no shutdown. 

Central# config t 

Central(config) # interface eth 0/0 
Central(config) # no shutdown 
Central (config) # end 

Depending on network speed and router model, this procedure may take about 5-20 
minutes. Note that, for some older Cisco router models, additional hardware-specific 
steps may be needed. Consult the release notes for the particular router for details. 

Transcript of a Successful Update Procedure 

The recorded transcript below shows an upgrade of a Cisco 3640 router from lOS 
11.3(4) to 12.0(5). 

South> show version 

Cisco Internetwork Operating System Software 

lOS(tm) 3600 Software (C3640-I-M), Version 11.3 (4)Tl, RELEASE SOFTWARE (fcl) 


South>show flash 

System flash directory: 

File Length Name/status 

1 3208548 c3640-i-mz.113-4,Tl 

[3208612 bytes used, 5179996 available, 8388608 total] 

8192K bytes of processor board System flash (Read/Write) 

South> enable 
Password: 

South# copy flash: tftp 

System flash directory: 

File Length Name/status 

1 3208548 c3640-i-mz.113-4.Tl 

[3208612 bytes used, 5179996 available, 8388608 total] 

Address or name of remote host [14,2.9.6]? 14.2.9.6 
Source file name? c3640—i—mz.113—4.Tl 

Destination file name [c3640-i-mz,113-4.Tl]? c3640—i—mz—113-4.Tl.bak 
Verifying checksum for 'c3640-i-mz.113-4.Tl' (file #1)... OK 
Copy 'c3640-i-mz.113-4.Tl' from Flash to server 
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as 'c3640-i-mz-113-4.T1,bak'? [yes/no]yes 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 1 1 !! M ! 
!!!!!!!!!! 

Upload to server done 

Flash device copy took 00:00:19 [hh:mm:ss] 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# interface ethernetO/1 

South(config-if)# shutdown 
South(config-if)# exit 
South(config)# exit 
South# 

%SYS-5-CONFIG_I: Configured from console by console 
South#copy running-config tftp 
Remote host []? 14.2.9.6 

Name of configuration file to write [south-confg]? south-config.bak 
Write file south-config.bak on host 14.2.9.6? [confirm] 

Building configuration... 

Writing south-config.bak !! [OK] 

South# copy tftp flash 

System flash directory: 

File Length Name/status 

1 3208548 c3640-i-mz.113-4,11 

[3208612 bytes used, 5179996 available, 8388608 total] 

Address or name of remote host [255.255.255.255]? 14.2.9.6 
Source file name? c3640—ik2o3s—mz_120—5_T1.bin 

Destination file name [c3640-ik2o3s-mz_120-5_Tl.bin]? c3640-ik2o3s—mz_120— 
5_T1.bin 

Accessing file 'c3640-ik2o3s-mz_120-5_Tl.bin' on 14.2.9.6... 

Loading c3640-ik2o3s-mz_120-5_Tl.bin from 14.2.9.6 (via EthernetO/0): ! 

[OK] 

Erase flash device before writing? [confirm] 

Flash contains files. Are you sure you want to erase? [confirm] 

Copy 'c3640-ik2o3s-mz_120-5_Tl.bin' from server 

as 'c3640-ik2o3s-mz_120-5_Tl.bin' into Flash WITH erase? [yes/no]yes 
Erasing device... eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee ...erased 
Loading c3640-ik2o3s-mz_120-5_Tl.bin from 14.2,9.6 (via EthernetO/O): 

!!!!!!!!!!! 

! I M M M M M M M I I M I I I I I I I M 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 !!!!!!!!!!!! ! 

[OK - 7656076/8388608 bytes] 

Verifying checksum... OK (0xDC3B) 

Flash device copy took 00:00:50 [hh:mm:ss] 

South# reload 

System configuration has been modified. Save? [yes/no]: no 
Proceed with reload? [confirm] 

%SYS-5-RELOAD: Reload requested 

System Bootstrap, Version 11.1(19)AA, EARLY DEPLOYMENT RELEASE SOFTWARE 
(fcl) 
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Copyright (c) 1998 by cisco Systems, Inc. 

C3600 processor with 32768 Kbytes of main memory 

Main memory is configured to 64 bit mode with parity disabled 

program load complete, entry point: 0x80008000, size: 0x74dl70 
Self decompressing the image : 

############################################# [OK] 


South> 

South> show ip interface brief 


Interface 

IP-Address 

OK? 

Method 

Status 

Protocol 

EthernetO/0 

14.2,9.64 

YES 

NVRAM 

up 


up 

EthernetO/I 

14.2.10.250 

YES 

NVRAM 

up 


up 

EthernetO/2 

unassigned 

YES 

NVRAM 

administratively 

down 

down 

EthernetO/3 

unassigned 

YES 

NVRAM 

administratively 

down 

down 


South> enable 
Password: 

South# show running-config 

Building configuration... 
Current configuration: 

version 12.0 

service timestamps debug uptime 


end 

South# exit 

Backing Out an Update 

If functional testing reveals a problem with your router after an upgrade, you may 
need to return to your old lOS version. Simply follow the procedure described 
above, starting with step 2. In step 3, use a different name than you used during the 
upgrade procedure. In step 4, load the backup copy of the old lOS software. Note 
that, if you have upgraded from one lOS major version to another (e.g. from 11.2 to 
12.0), your stored configuration might not work correctly when you fall back to the 
older version. In that case, restore the backup copy of the configuration that you 
saved during the upgrade procedure step 1. 

Central# copy tftp flash 

Central# reload 


Central# ! Optional, restore old configuration 
Central# copy tftp running-config 
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Additional Security Concerns 

There are several security issues surrounding upgrades, this section attempts to 
address them. 

First, if you follow the installation procedure outlined above, you transmit a copy of 
your router configuration to a TFTP server. Because TFTP provides no security, it is 
critical that you protect the TFTP transaction and server from potential attackers. 
There are several approaches to doing this, but the simplest is to ensure that the TFTP 
traffic does not traverse hostile networks. Also, do not leave TFTP enabled on your 
host; always turn it off immediately after you finish the installation procedure. 

Second, whenever you make any kind of backup copy of a router configuration, you 
may be exposing your encrypted passwords to disclosure. The simplest approach to 
mitigating this risk is to change the enable secret immediately after installation (see 
Section 4.1). 

Third, many default settings differ between various lOS releases. Some of these 
settings can affect your router’s security. Also, some newer versions offer services 
not present in older versions. 


4.5.6. Diagnosing and Debugging Router Operation 

Effective logging and SNMP help an administrator to stay aware of their routers’ 
status and operational condition. When a problem occurs, or when a network is 
under attack, Cisco lOS diagnostic and debug facilities can be used to get vital 
information, identify sources and causes, and validate repairs. 

Techniques for troubleshooting and debugging routers could (and do) fill entire 
books. This short sub-section describes some of the most useful techniques for lOS 
11.3 and 12.0. The techniques fall into three groups: 

■ Router status and configuration commands - 

These commands display information about that settings and tables held by 
the router; some of this information is global to the whole router, and some 
is particular to each interface. 

■ Router throughput and traffic commands - 

Each interface, and some other facilities, keep input/output statistics. 

There are lOS commands to display these statistics that can be used to 
detect problems. 

■ Debugging commands - 

Virtually every lOS facility and protocol has associated debugging 
commands, and they offer a great deal of visibility into the operation of the 
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router. These commands typically produce a correspondingly great deal of 
output, so use them sparingly. 

These commands can also be used to help verify that security measures are in force. 
Testing and validation are covered in Section 6. 

Router Status and Configuration Commands 

Each of the items below describes a single status query. There are literally hundreds 
of such queries available, even on the simplest Cisco routers. The ones listed here 
are commonly used for troubleshooting, and are useful for understanding a Cisco 
router’s disposition in a typical TCP/IP network. 

1. Viewing the current log - 

To view the current buffered log messages, use the command show 
logging. The output consists of two parts: a summary of the current 
logging configuration, and the log messages. The messages are shown in 
the order they occurred, so recent messages are at the end of the listing. 
The buffered log messages are cleared when the router reboots, so the 
first few messages put into the log reflect startup activity. In the example 
below, an unauthorized attempt to telnet to the router itself has been 
logged by access list 131. For more discussion of logging, consult 
Section 4.5.2. 

East# show logging 

Syslog logging: enabled (0 messages dropped, 0 flushes) 
Console logging: level debugging, 56 message lines logged 
Monitor logging: level debugging, 32 message lines logged 
Buffer logging: level debugging, 56 message lines logged 
Trap logging: level informational, 33 message lines logged 
Logging to 14.2.9.6, 33 message lines logged 

Log Buffer (16000 bytes): 

00:00:17: %LINK-3-UPDOWN: Interface EthernetO, changed 
state to up 


Mar 3 12:51:52 EST: %SEC-6-IPACCESSLOGP: list 131 denied 
tcp 172.17.101.250(47746) -> 0.0.0.0(23), 1 packet 
East# 


Note: log messages should always include the time of the event. In a 
router using NTP, the first few log messages will include the time since 
boot instead of the correct time, because the messages are generated 
before NTP has synchronized. 


Version l.Og 


UNCLASSIFIED 


131 





Router Security Configuration Guide 


UNCLASSIFIED 


2. Viewing the current route table - 

To view the current route table, use the command show ip route. 
Depending on the size of the network and the kinds of routing protocols 
used, this list may be very large. A very important part of reviewing the 
route table is checking the route codes and checking the destination 
gateway. Each route code identifies how one route joined the table; the 
destination gateway is simply the next hop on that route. Check the route 
codes to make sure that all the routes joined the table either directly 
(code C), or were added as static routes (code S), or were added by a 
configured routing protocol (codes R, O, and others, see Section 4.4). 

The figure below shows how to interpret the output of show ip route. 



Figure 4-8: Interpreting Route Table Output 

3. Viewing the routing protocols in use - 

The command show ip protocol gives a verbose listing of the route 
update mechanisms currently used on the router. The output is different 
for each kind of protocol. The command show ip protocol 
summary gives a quick overview. All of the individual routing protocols 
also have extensive status commands, see Section 4.4 for some 
recommendations. The example below shows the IP routing protocol 
summary and the output for a useful OSPF status command 
(abbreviated). 

Central# show ip protocol summary 

Index Process Name 

0 connected 

1 static 

2 ospf 1 

3 rip 

Central# show ip ospf neighbor 

Neighbor ID Pri State Dead Time Address Interface 

14.2.1.20 I FULL/DR 00:00:33 14.2.1.20 EthO/0 

14.2.1.250 1 FULL/DR 00:00:38 14.2.1.250 EthO/0 

Central# 
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4. Viewing the current ARP table - 

Extraneous devices, mis-connected devices, and unauthorized devices on 
a network segment can often be detected by their presence in a router’s 
address resolution (ARP) table. To display the ARP table, use the 
command show arp, as in the example below. 


Central# 

Protocol 

show arp 

Address 

Age(min) 

Hardware Addr 

Type 

Interface 

Internet 

14.2.9.6 

57 

0004.acd5.f3f6 

ARPA 

EthO/1 

Internet 

14.2.1.20 

10 

0010.7bf9.127a 

ARPA 

EthO/0 

Internet 

14.2.9.64 

43 

0050.0f03.3680 

ARPA 

EthO/1 

Internet 

14.1.1.250 

53 

0010.7bb6.baa0 

ARPA 

EthO/0 


Central# 

5. Viewing the logged in users - 

The command show users displays a list of users that are currently 
logged in. In the example output below, there is one user logged in at the 
console, and two are logged in over the network. 


Central# show users 

Line User 

0 con 0 jsmith 

130 vty 0 andrew 

*131 vty 1 neal 

Central# 


Host(s) Idle Location 
idle 00:00:56 

idle 00:01:02 14.2.1.20 

idle 00:00:00 14.2.9.6 


6. Viewing host name and name lookup information - 

Cisco lOS uses two mechanisms for mapping between IP addresses and 
names: locally defined names, and DNS. Locally defined names take 
precedence over DNS names. Use the command show host to display 
the DNS configuration and the list of locally defined names. 

Central# show host 
Default domain is not set 
Name/address lookup uses domain service 
Name servers are 14.1.1.2, 14.2.9.1 


Host 

Flags 


Age 

Type 

Address(es) 

east 

(perm, 

OK) 

4 

TP 

14.1.1.20 

central 

(perm. 

OK) 


IP 

14.1.15.250 

south 

(perm. 

OK) 

52 

IP 

14.2.9.64 


Central# 

7. Viewing interface status and configuration - 

Use the command show ip interface to view a verbose display of 
the status and configuration of a router’s network interfaces. For a quick 
look, use the command show ip interface brief. In all cases, the 
listing will include both active and inactive interfaces. The example 
below shows the brief output format, slightly abbreviated. 

Central# show ip interf brief 
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Interface 

IP-Address 

OK? 

Method 

Status 

Protocol 

EthernetO/0 

14.1.15.250 

YES 

NVRAM 

up 

up 

EthernetO/1 

14.2.9.250 

YES 

NVRAM 

up 

up 

EthernetO/2 

unassigned 

YES 

unset 

down 

down 

EthernetO/3 

Central# 

unassigned 

YES 

unset 

down 

down 


8. Viewing line status - 

Every Cisco router has at least one physical line connection, the console, 
and typically five virtual line connections, the telnet vty lines. Use the 
command show line to display a summary of lines available on a 
router. To display the full status of a line, use show line name 
number, for instance, show line aux 0. 

9. Viewing currently open TCP socket connections - 

Use the command show ip socket to list the currently open network 
service sockets on the router. The output is a little cryptic, but can 
provide valuable clues to the services that the router is actually 
providing. The example below shows the output for a router mnning 
fairly few services. 

Central# show ip sockets 


Protc 

1 Remote 

Port 

Local 

Port 

In 

Out 

Stat 

TTY 

17 

0.0.0.0 

520 

14.1.15.250 

520 

0 

0 

1 

0 

17 

14.2.9.1 

36269 

14.1.15.250 

161 

0 

0 

I 

0 

17 

0.0.0.0 

123 

14.1.15.250 

123 

0 

0 

I 

0 

17 

14.2.9.6 

514 

14.1.15.250 

6082 

0 

0 

10 

132 


Central# 


The first line is the RIP route protocol service (local port 520). The 
second line is the SNMP service to a host mnning an SNMP/RMON 
management tool (local port 161). The third line is the network time 
service (NTP, port 123). The fourth line is the logging client, sending 
syslog messages to a Unix host (remote port 514). 

10. Viewing the current configuration - 

To view the current mnning lOS configuration, use the command show 
running. The resulting output will typically be fairly long. To review a 
configuration in depth, save the command results to a file, print it, and 
review the hardcopy. To view the saved startup configuration (in 
NVRAM) use show startup. Normally, these two configurations 
should be very similar. If the configurations are very large and complex, 
use a file comparison tool, such as Unix or Windows/c, to highlight 

the differences. 

Archive a copy of the configuration after any major change, or on a 
monthly basis. This can help with problems, and also shorten downtime 
if the router loses its stored configuration. The example below shows 
how to save an archive copy of a configuration to an FTP server, using 
lOS 12.0. 
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Central# config t 

Enter configuration commands, one per line. End with 
CNTL/Z. 

Central(config)# ip ftp password 0 rOutSrQQ 

Central(config)# ip ftp user rscg 

Central(config)# exit 

Central# copy running-config ftp 

Address or name of remote host []? 14.2.9.1 
Destination filename [central-confg]? central-config.txt 
Writing central-config.txt !! 

5699 bytes copied in 12.716 secs (474 bytes/sec) 

Central# 


In lOS 11.3 and earlier, FTP is not supported, but TFTP can be used for 
making archive copies in a very similar manner (see Section 4.5.5). 
Because TFTP is insecure, it should be used with care and disable d when 
not in use. Another way to get an archive copy of the mnning 
configuration is to use text logging features of Telnet and terminal 
emulation applications. 

11. Viewing currently running processes - 

Many lOS services and facilities mn as separate lOS processes. Use the 
command show process to list the mnning processes. The output is 
usually quite long. 


Router Throughput and Traffic Commands 

The commands listed below display various traffic statistics that can be useful in 
diagnosing router traffic flow. Understanding normal network and link traffic loads 
can be critical for identifying anomalous conditions that are indications or warning of 
attacks. Most of these commands produce voluminous but clearly formatted output. 

1. Viewing the network traffic on a per-interface basis - 

To view the total traffic for each interface, use the command show 
interface. This will display a comprehensive report on the traffic 
through all the interfaces. To view the traffic for a single interface, 
simply supply that interface name to the command. The example below 
shows the output format for a single Ethernet interface. 

Central# show interface eth 0/0 

EthernetO/0 is up, line protocol is up 
Hardware is AmdP2, address is 0050.7357.cbeO 
Internet address is 14.1.15.250/24 


Last clearing of "show interface" counters 23:20:53 


991606 packets input, 103806395 bytes, 0 no buffer 
Received 800624 broadcasts,0 runts,0 giants,0 throttles 
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0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 
0 input packets with dribble condition detected 
480919 packets output, 38371898 bytes, 0 underruns 
0 output errors, 78 collisions, 1 interface resets 
0 babbles, 0 late collision, 215 deferred 
0 lost carrier, 0 no carrier 

0 output buffer failures, 0 output buffers swapped out 
Central# 


If traffic volume monitoring is important for a particular interface, then 
clear the counters on a periodic basis. Clearing the counters sets the 
traffic volume record back to zero for both input and output. The 
example below shows how to clear the counters for a single interface. 

Central# clear counter Eth 0/0 

Clear "show interface" counters on this interface 
[confirm]y 

Central# 

2. Viewing IP Protocol Statistics - 

To display a long listing of IP and related protocol traffic statistics, use 
the command show ip traffic. The output is quite long, but can 
reveal certain classes of attacks. 

3. Viewing SNMP Protocol Statistics - 

To display the SNMP messages statistics and configuration, use the very 
simple command show snmp. If the output shows any SNMP traffic, 
and the network does not have an SNMP infrastmcture deployed, then 
the router may have been subjected to an SNMP sweep by an attacker. 
The example below shows the output for a router with a very modest 
amount of SNMP traffic. 

Central# show snmp 
Chassis: Central 
Contact: Vanessa & Phyl 
Location: second floor 
73 SNMP packets input 

0 Bad SNMP version errors 
0 Unknown community name 

0 Illegal operation for community name supplied 
0 Encoding errors 

263 Number of requested variables 
0 Number of altered variables 
10 Get-request PDUs 
63 Get-next PDUs 
0 Set-request PDUs 
73 SNMP packets output 

0 Too big errors (Maximum packet size 1500) 

2 No such name errors 
0 Bad values errors 
0 General errors 
73 Response PDUs 
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0 Trap PDUs 

SNMP logging: disabled 
Central# 


The only way to clear these statistics is to reset the router. 

Router Debug Commands 

Cisco lOS offers a very extensive suite of debugging commands. Each debugging 
command is associated with a particular service, facility, or feature of the router. 
When debugging is enabled for a particular protocol or feature, all activities of that 
protocol or feature will generate log messages at level 7. 

Debug messages, when generated, are sent to all log sources configured to receive 
them. The number of messages generated by debugging can often be quite large. 
Therefore, when using the debug messages for interactive troubleshooting, be sure to 
configure the buffered log and syslog for level 6 (informational). The example below 
shows how to configure debugging, and turn on debugging messages for ICMP. 

Central# show users 

Line User Host (s) Idle Location 

*130 vty 0 rscg idle 00:00:00 14.2.9.6 

Central# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Central(config)# logging console information 

Central(config)# logging monitor debug 

Central(config)# logging buffered information 

Central(config)# logging trap information 

Central(config)# exit 

Central# 

Mar 3 17:01:58.159 EST: %SYS-5-CONFIG_I: Configured from console by 
nziring on vtyO (14.2.9.6) 

Central# term monitor 
Central# debug ip icmp 

ICMP packet debugging is on 

Central# ! At this point, "ping central" was performed on 14.2.9.6 

Mar 3 17:02:13 EST: ICMP: echo reply sent, src 14.2.9.250, dst 
14.2.9.6 

Central# no debug ip icmp 

ICMP packet debugging is off 
Central# 


The Cisco documentation set includes a volume with comprehensive information 
about the debug facilities and their behavior, the Cisco lOS Debug Command 
Reference. 
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4.6. Security for Router Network Access Services 

Security for Network Access Services deals primarily with controlling remote users 
who are accessing local resources. An Internet Service Provider would be a good 
example of this. Cisco provides this security with their authentication, authorization, 
and accounting (AAA) services. The sub-section below dealing with dialin users 
will give an introduction to controlling remote users accessing network resources. 
But the majority of this section will cover using Cisco’s AAA services for controlling 
access to a router and the security server protocols. 

4.6.1. Overview, Basic Concepts, and Support Mechanisms 

Cisco’s authentication, authorization, and accounting services provide critical 
security functions necessary for providing remote access to routers and network 
resources. AAA is the mechanism Cisco recommends for access control. AAA is 
designed to allow the administrator to configure its services globally or by line and 
interface. Configuration is performed by using method lists as described later. 

When AAA services are enabled on a Cisco router, the older forms of access control 
are disabled. This means that you can no longer access the commands to configure 
the older protocols (including login local and login commands). Where the 
older access control mechanisms dealt almost solely with user authentication, AAA 
also has the ability to control each user’s access to resources and provides additional 
accounting capabilities beyond the router’s logging facilities. AAA allows you to 
employ the following sources of user information: RADIUS, TACACS-i-, Kerberos, 
the local database, enable, and line passwords. 

By using AAA along with a security server you can control access to routers and 
other network services from a centralized location. This allows for easier 
management of user accounts and privileges, and provides additional capabilities for 
auditing of network service usage. When using the local database instead of a 
security server AAA is very limited in it's authorization capabilities and provides no 
mechanism for accounting. RADIUS, TACACS+, and Kerberos security servers 
provide the services required for AAA, except Kerberos does not accept accounting 
records. Communications with the three remote security servers are protected, but 
the initial login still allows the password to traverse the network in the clear. So the 
remote terminal should be located on the internal network to remotely access the 
router (see section 4.1.5). There are three conditions when using a security server 
can be very effective: 

1. when flexible authorization capabilities are required, 

2. when accounting is required and, 

3. when there a large number of routers so that centralized administration 
becomes advantageous. 
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Additionally, AAA also allows you to configure backup methods for the different 
services using method lists. Examples in this section will use a subset of the main 
network diagram as shown in the "Putting It Together" sub-section in 4.6.2. The 
following sections will discuss the three services provided by AAA and their 
supporting concepts. 

Authentication 

Authentication is the mechanism for identifying users before allowing access to 
network components or services. In other words, authentication controls the ability 
of a user or another network component to access a network device or service. AAA 
authentication provides the means for identifying users through login/password 
dialogs, challenge/response mechanisms, and supported token technologies. 

Although authentication can be configured without using AAA (see Section 4.1), to 
use security server protocols or backup authentication methods you must use AAA 
authentication. For AAA authentication the available methods are RADIUS, 
TACACS-I-, Kerberos, local username database, line passwords, enable passwords 
and none. 

AAA authentication is setup using method lists. This can be done by a combination 
of named lists and the default list (see complete description of method lists see sub¬ 
section below). Named lists must be applied to the appropriate lines and interfaces. 
The default method list will be automatically applied to all the lines and interfaces for 
which a named list was not applied. The authentication method list defines the types 
of authentication to be performed and the sequence in which to apply them. 

Configuring AAA authentication requhes: enable AAA authentication, setup 
security protocol server parameters, setup method lists for AAA authentication, and 
apply the method lists to a particular interface or line, if required. When AAA 
authentication has not been set up the default will use the local username information 
and when there is no username information vty’s are locked out. The console 
automatically lets you in when AAA authentic ation has not been applied to the 
console. When authentication has been applied to a line or interface and no AAA 
methods work, then you will be locked out of the router. An important note, when 
AAA is enabled and a default list not defined and there is not a named list applied to 
the interface or line then by default authentication will use the local database. 

Section 4.6.2 demonstrates how to setup AAA authentication. 

For more information about applying AAA authentication to a Cisco router see 
Section 4.6.2. Cisco provides more information in the "Configuring Authentication" 
chapter of the Security Configuration Guide [1]. 

Authorization 

Authorization controls access to system resources. Authorization is the method used 
to describe what a user has the right to do once they are authenticated to the router. 
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Authorization includes one-time authorization, authorization for each service, and 
authorization for each user. Additionally, authorization can only be configured using 
AAA. Authorization method lists can include RADIUS and TACACS-i- security 
protocols along with Kerberos Instance Maps, if-authenticated, and local (which is 
very limited) methods. 

As with authentication, method lists define what authorization protocols will be used 
and in what order. Authorization commands with method lists do not need to be 
named or use default. If they are unnamed they automatically apply to all interfaces 
and lines for that type of traffic. There is a special case for the console line, if a user 
has been authenticated when logging into the console line then authorization will not 
be used (even if configured). Default method lists are applied to all lines and 
interfaces for that particular authorization type. But named method lists, other than 
default must be applied to the interface or line to be invoked. AAA authorization 
types are: 


■ exec - which controls the users ability to mn an EXEC shell. 

■ commands <level> - which controls access to all the commands at the 
specified privilege level. 

■ network - enables authorization for all network related services like: PPP, 
PPP NCP’s, SLIP, and ARA Protocols. 

■ reverse-access - controls access to all reverse access connections like 
reverse Telnet. 

Authorization lists are specific to the authorization type which is being defined. If no 
authorization list is defined for the authorization type then no authorization will occur 
for that type. 

Prerequisites to AAA authorization: enable AAA services, configure AAA 
authentication (since authorization relies on authentication's output),define security 
servers, and define the rights for each user. The RADIUS and TACACS-i- security 
servers, as described in Section 4.6.4, use attribute-value pairs to define a user's 
rights. Authorization works by creating a list of attributes which describe what the 
user is allowed to do. When a user logs in and has been identified by authentication, 
then the security server database will be used to control access to various network 
components and services as defined by the stored attributes. 

Eor more information about configuring authorization using AAA, refer to the 
"Configuring Authorization" chapter in the Security Configuration Guide. 

Accounting 

AAA accounting is used for logging and tracking the activities of users (people or 
other network components) using a network resource. These logs can be used for 
network management, security analysis, resource usage tracking, and reporting. 
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Routers send their accounting records to the security server for storage. Information 
in an accounting record includes the users identity, the usage start and stop times, 
number of packets and bytes, and the command that was executed. AAA accounting 
can only use the TACACS+ or RADIUS security servers for record logging. 

As with authentication and authorization, you configure AAA accounting by defining 
a list of accounting methods. If the list was a named list then it must be applied to 
the appropriate lines and interfaces. The list will define the list of accounting 
methods for the indicated accounting type. For an accounting type, if a default list is 
not defined and a named list is not applied to the line then no accounting will occur 
for that type on that line. 

There are several types of accounting which can be turned on: exec, network, 
connection, command, system. All types are supported by TACACS+, but RADIUS 
does not support command or system. 

■ network accounting - Provides information for PPP, SLIP, and ARAP 
protocols. The information includes the number of packets and bytes. 

■ EXEC accounting - Provides information about user EXEC sessions on 
the network access server. The information includes the username, date, 
start and stop times, IP address of access server, and telephone number the 
call originated from for dial in users. 

■ connection accounting - Provides information about all outbound 
connections made from the network access server. This includes telnet, 
rlogin, etc. (local-area transport (EAT), TN3270, packet 
assembler/disassembler (PAD)). 

■ commands - This applies to commands which are entered in an EXEC 
shell. This option will apply accounting to all commands issued at the 
specified privilege level. If accounting is turned on for level 15 and user 
logged in at enable level 15 runs a level 1 exec command no audit event 
will be generated. Account records are generated based upon the level of 
the command not the level of the user. Accounting records will include 
the command, date, time, and the user. Cisco's implementation of 
RADIUS does not support command accounting. 

■ system - Provides information about system-level events. This would 
include information like system reboots, accounting being turned on or off, 
etc. Note that system accounting will only use the default list. Cisco’s 
implementation of RADIUS does not support system accounting. 

AAA accounting requires that AAA is enabled, security servers are defined, and that 
a security server is specified for each accounting type which is desired. Each 
accounting record is comprised of accounting AV pairs and is stored on the access 
control server. Accounting can also be configured such that a user requested action 
can not occur until an acknowledgement is received from the security server stating 
that the accounting record has been saved. 
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For more information about AAA accounting, including RADIUS and TACACS+ 
attributes, see the Security Configuration Guide. 


Method Lists 

Method lists are used to specify one or more security protocols or mechanisms for 
AAA. Method lists also specify the sequence in which the security mechanisms 
should be used. These lists can be used to provide backup mechanisms for when the 
primary security method is unavailable. For AAA the Cisco lOS software will use 
the first method listed to perform the authentication, authorization, or accounting as 
appropriate. If the Cisco lOS software is unable to complete the task due to failure to 
communicate with the security server or mechanism then the Cisco lOS will try the 
next method in the list. This continues until there is a successful communication with 
a listed method or the list is exhausted. If the list is exhausted then the mechanism 
will fail. In the case of authentication and authorization the user will be denied 
access. In the case of accounting the auditing event will not occur, except for wait- 
start accounting which will also deny the user access for the service. Note: a 
negative response from a security server will also deny access in the case of 
authentication and authorization and the next method in the list will not be attempted. 

Method lists can be given a specific name or can use the keyword default. When a 
method list is specified using the default keyword the list will be automatically 
applied to all the appropriate interfaces and lines. Named access lists can then be 
defined and then applied to the particular interface or line to override the default 
behavior. This also means that a named method list will have no effect on a interface 
or line unless it has been applied to it. Methods requiring only a password should 
never be placed ahead of methods requiring a username and password, since the user 
will never be prompted for a username. A special case, seems to exist for the local 
database in that if a username does not exist the next method will be attempted. 
(RADIUS, TACACS-I-, and Kerberos security servers will deny access if the 
username does not exist and the server is available.) 

The following example shows a named method list for AAA authentication, and 
default lists for authorization and accounting for network traffic: 

aaa authentication login remoteauthen radius local 
aaa authorization network default radius local 
aaa accounting network default start-stop radius 

4.6.2. Router Access Control 

The previous section introduced authentication, authorization, and accounting 
mechanisms and how method lists are used to define the security protocol to use for a 
service. This section will cover details of configuring AAA for controlling access to 
the router. Section 4.6.3 briefly covers a dial-in user example. Cisco's ACS Version 
2.3 was used for testing RADIUS and TACACS-i- security servers. Section 4.6.4 
describes security server protocols in more detail. 


Version l.Og 


UNCLASSIFIED 


143 





Router Security Configuration Guide 


UNCLASSIFIED 


In order to use Cisco's AAA mechanisms you must first enable AAA services, the 
command for doing this is: 

aaa new-model 

The remainder of this section will deal with configuring the three AAA services by 
giving concrete examples (see Figure 4-8 on page 149) and describing the rationale 
behind the configuration. 


Authentication 

The AAA authentication commands can be grouped into two areas which correspond 
to how they are applied. First there is directly controlling authentication to the router 
and then there are commands for providing information about the authentication 
process. The four authentication commands used for controlling access to a router 
are: 


■ aaa authentication login {default | list-name} method-list 

is used to specify login authentication method lists. 

■ aaa authentication enable default method-list can be used to 
control access to enable mode with the authentication mechanism. 

■ aaa authentication local-override is used to override all 
authentication method lists to look at the local database first. This 
command will also require that all authentication requests to the router 
include a username as well as a password. 

■ (line) : login authentication {default | list-name} is 
required to apply a named login authentication method list to a line. There 
is never really a need to use the "default" option but it could be used to be 
more explicit, and avoid possible default behavior changes in the lOS. 

Four authentication commands are used for messaging to the user. The commands 
deal with prompts and informational messages. Using these commands in your 
environment may be a useful thing to do. There is an important point to remember 
when setting prompts and messages: Do Not Give Away To Much Information! 

Like specifying why AAA failed with the aaa authentication fail^essage 
command, it is better to stick to generic responses and allow the administrator to look 
in the audit records for debugging purposes. Another bad example would be using an 
informational banner to tell people this is your bastion router or this router protects a 
special enclave. The authentication commands used for messaging are: 

■ aaa authentication username-prompt text-string changes the 
username prompt from "Username" to the defined value of text-string. 

■ aaa authentication password-prompt text-string changes the 
password prompt from "Password" to the defined value of text-string. 
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■ aaa authentication banner delimiter string delimiter 

replaces any before system login banners with the value of string. 

■ aaa authentication fail-message delimiter string delimiter 

will replace the default message for a login value with the value of string. 

This section will concentrate on the four authentication commands for controlling 
access to the router. For setting a banner on all terminals use the banner motd 
command as suggested earlier in Section 4.1.4. 

In a simple situation only one authentication list is required. This list should be the 
default list, to guarantee all lines are protected, and should include a local method. 
Including a local method will guarantee that if the security server(s) is not available 
that an administrator will still have access to the router. Remember to add at least 
one administrator to the local database. 

Central(config) # username joeadmin password 0 G0oD9pa$8 
Central(config) # aaa authentication login default radius local 

One note about method lists for aaa authentication, what ever method is first, controls 
whether the authentication procedure will prompt for a username or not. So if the 
first method in the list is line or enable, then any additional method which requires a 
username will automatically fail. So when generating method lists decide whether to 
use usernames and passwords or just use a password. For accounting purposes you 
should use the methods which allow for usernames and assign each administrator a 
distinct username. 

In a more complex scenario where a more limited set of administrators have access to 
the console line first create the default list again. The default list should be for the 
limited set of administrators and should use the local database. Additionally the 
default list should be developed to protect the console line. Accounting records can 
still be sent to the security server but the security server's authorization capabilities 
can not be used since no authentication records will be sent to the security server. 

The second list should be a named method list and should be applied to the 
appropriate lines to allow additional administrators onto the router. For the named 
method list which will primarily use the security server, authorization can be used to 
control the larger set of administrators. The following is a recommended 
configuration for using a TACACS+ security server and the local database. 

Central(config) # username annadmin password 0 G%oD9pa$8 
Central(config) # username joeadmin password 0 badpasswd 
Central(config) # aaa authentication login default local 
Central(config) # aaa authentication login remotelist radius local 

Central(config) # line vty 0 4 

Central(config-line) # login authentication remotelist 

Central(config) # line aux 0 

Central(config-line) # login authentication remotelist 

In general the default list should be the most restrictive authorization list. When 
multiple lists are used it would be a good idea if the default list only used the local 
method and then named lists can be used to override the default list as appropriate. 
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Important: when AAA is turned on, then by default, authentication will use the local 
database on all lines. To avoid being locked out of the router make sure you add an 
administrator account to the local username name database before enabling AAA 
authentication. 

Do not use aaa authentication enable default command since the security 
server pass phrase is stored in the clear and only enable secret is well protected. Use 
the enable secret password to protect all higher privilege levels. 

Authorization 

The commands used for AAA authorization are: 

" aaa authorization {network | exec | commands level \ 

reverse-access} {default | list-name) method-list turns on 
AAA authorization for the specified type and designates the order in which 
authorization methods will be applied. 

■ aaa authorization conf ig-commands tells the router to do 

authorization on all configuration commands (this is the default mode set 
by the aaa authorization commands level command). The no form 
of this command will turn off authorization on configuration commands in 
the EXEC mode. 

" (line): authorization {arap | commands level | exec | 
reverse-access) {default | list-name) applies a specific 
authorization type to a line (note: arap is part of the network authorization 
type). 

Of the four authorization types, exec and command apply to router access control and 
apply to lines, the other two (network and reverse-access) primarily deal with dial-in 
and dialout access control and apply to interfaces. Another network type, arap, is 
also applied to lines, and will not be covered. This section will concentrate on exec 
and command authorization and section 4.6.3 on DiaUn Users overviews network 
and reverse-access authorization. 

AAA authorization is currently of limited use for controlling access to routers beyond 
the standard authentication mechanisms. There are two primary scenarios where 
authorization is useful. Eirst, if the router is used for dial in access, authorization is 
useful for controlling who can access network services, etc. and who can access and 
configure the router. Second, authorization can control different administrators who 
have access to different privilege levels on the router. 

Scenario 1 - Router with dial-in users, authorization configuration for controlling 
access to the router: 

Central(config) # aaa authorization exec default radius 
Central(config) # aaa authorization network default radius 
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Scenario 2 - Router with two levels of users (exec and privileged exec) 

Central(config) # aaa authorization exec default radius 
Central(config) # aaa authorization commands 15 default radius 

In both scenarios there was no need to apply the authorization method lists to lines 
because they are using the default lists. For scenario 1 there would be additional 
considerations as described in the Dial-In Users section. In scenario 2, exec is used 
to control all access to exec shells on the router and commands 15 is used to control 
access to privilege level 15 for a more restrictive set of administrators. The router 
commands turn on the checks to query the security server on the router but the actual 
user to authorization privilege mapping occurs on the security server. 

RADIUS and TACACS-i- authorization both define specific rights for users by 
processing attributes, which are stored in a database on the security server. For both, 
RADIUS and TACACS-i-, attributes are defined on the security server, associated 
with the user, and sent to the network access server where they are applied to the 
user's connection. For a list of supported RADIUS attributes, refer to the "RADIUS 
Attributes" appendix. For a list of supported TACACS-i- AV pairs, refer to the 
"TACACS-I- Attribute-Value Pairs" appendix. 

The local database is populated using the username command. But there are no 
useful parameters to set for access to the router from lines (exception would be fcr 
dial in access). Important: do not use the username name privilege level command 
since the password will be weakly protected. Protect higher levels on the router 
using the enable secret command (see Section 4.1). 

Also, in the examples above if the RADIUS security server is not available no one 
will be able to get an exec shell and in scenario 2 no one will be able to mn privilege 
level 15 commands. There is one very important exception to this, AAA 
authorization does not apply to the console line. Even if a named method list is 
created and applied to the console line authorization will be ignored. 

Accounting 

The commands used for AAA accounting are: 

■ aaa accounting {system | network | exec | connection | 
commands level] {default | list-name] {start-stop | wait- 
start I stop-only I none} method-list turns on AAA's 
accounting services for the specified accounting type. 

■ aaa accounting suppress null-username command prevents 
accounting records from being generated for those users who do not have 
usernames associated with them. (NULL usernames can occur because of 
accounting records on a protocol translation) 

■ aaa accounting update {newinfo 1 periodic number} will allow 
administrators to specify when accounting records are sent to security 
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servers. Periodic generates more accounting records than newinfo since it 
will also include interim reports on actions in progress. 

■ (line): accounting {arap | commands level \ connection | 
exec} [default | list-name] can be used to apply different 
accounting services and le vels to different lines. 

■ show accounting {system | network | exec | commands level] 
{start-stop I wait-start | stop-only} tacacst command can 
be used to show active connection information. This is not a configuration 
command but is worth mention. 

AAA allows for four levels of accounting as set by the aaa accounting command: 

■ start-stop accounting sends records when the accounting type starts and 
stops. This is all done in the background and the user process will 
continue regardless of the outcome of the accounting attempt. 

■ wait-start accounting sends an accounting record at the start and stop of 
each specified type. In this case the user process can not continue, and 
will actually be terminated, if the start accounting record can not be 
recorded. If the start record is sent and acknowledged the user process can 
continue and at the end a stop accounting record will also be sent. 

■ stop-only sends an accounting record at the end user process which is of an 
accountable type. 

■ none specifies that no accounting records will be generated for a particular 
accounting type. 

Important: if wait-start accounting is specified on an interface or line and no security 
server is available for receiving the accounting record then the user process using that 
interface or line will be locked out. So don't use wait-start on the console line! A 
basic recommendation would be to use wait-start for remote users and start-stop for 
local users. For command accounting stop-only will provide the necessary coverage 
and will greatly reduce the number of accounting records. 

As mentioned earlier Cisco's RADIUS implementation does not support system and 
command accounting. Therefore, there are two basic scenarios for accounting 
depending upon which security server is in use. 


Configuration of TACACS-i- accounting: 


Central 

Central 

Central 

Central 

tacacst 

Central 

tacacst 

Central 

Central 


(config)# 
(config)# 
(config)# 
(config)# 


aaa accounting system default start-stop tacacs+ 
aaa accounting exec default start-stop tacacst 
aaa accounting exec remoteacc wait-start tacacs+ 
aaa accounting commands 15 cmdacc stop-only 


(config)# 


aaa accounting connection default start-stop 


(config)# line vty 0 4 

(config-line) # accounting exec remoteacc 
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Central(config-line) # accounting commands 15 cmdacc 

Central(config) # line aux 0 

Central(config-line) # accounting exec remoteacc 
Central(config-line) # accounting commands 15 cmdacc 

Configuration of RADIUS accounting: 

Central(config) # aaa accounting exec default start-stop radius 
Central(config) # aaa accounting exec remoteacc wait-start radius 
Central(config) # aaa accounting connection default start-stop 
radius 

Central(config) # line vty 0 4 

Central(config-line) # accounting exec remoteacc 

Central(config) # line aux 0 

Central(config-line) # accounting exec remoteacc 

Since remote administration is more dangerous than console administration, the 
configurations above add extra accounting to the remote lines. Part of the extra 
protection is requiring that before a remote user can get an exec shell an audit record 
must be recorded into the security server. Note: the aux line configuration is not 
required if the aux line is disabled as suggested in Section 4.6.2. Also, for 
information about RADIUS Attributes and TACACS+ AV Pairs for use in 
accounting, refer to the appendices in the Cisco Security Configuration Guide. 


Putting It Together 

This section will put together the AAA mechanisms from earlier in this section and 
will apply them to the configuration of the Central and South Routers. The Central 
router is between the facility backbone and the specific department in the 
infrastructure. The South router acts as the first layer of defense to a well protected 
enclave. 
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Figure 4-9: Routers and their Authentication Server 

Authorization will not be used in these examples since all the administrators in these 
examples need configuration access and there is no dial in access. For a more 
complete example, including authorization and some discussion of dial in security 
concerns, see Section 4.6.3. 


Central Router Configuration: 


Central(config)# 
Central(config)# 
Central(config)# 
Central (config)# 
Central (config)# 
Central(config)# 


enable secret 3rRsci$y 
username fredadmin password d$oyTldl 
username bethadmin password hsOoSTaG 
username johnadmin password an0!h3r( 
service password-encryption 
banner motd 


Aiji 


Central(config)# 
Central(config)# 
Central(config)# 
Central (config)# 
Central (config)# 
Central(config)# 
Central (config)# 
radius 

Central(config)# 
Central(config)# 


radius-server host 14.2.6.18 
radius-server key i*Ma5in@u9p#s5wD 
aaa new-model 

aaa authentication login default radius local 
aaa accounting exec default start-stop radius 
aaa accounting exec remoteacc wait-start radius 
aaa accounting connection default start-stop 

access-list 91 permit 14.2.9.0 0.0.0.255 log 
access-list 91 deny any log 


150 


UNCLASSIFIED 


Version l.Og 










































UNCLASSIFIED Implementing Security on Cisco Routers 


Central(config)# line 
Central(config-line)# 
Central(config-line)# 
Central(config-line)# 
Central(config-line)# 
Central(config)# line 
Central(config-line)# 
Central(config-line)# 
Central(config-line)# 
Central(config-line)# 
Central(config-line)# 
Central(config-line) # 
Central(config)# line 
Central(config-line)# 
Central(config-line) # 
Central(config-line)# 
Central(config-line) # 
Central(config-line) # 


con 0 

transport input none 
exec-timeout 5 0 
login local 
exit 
vty 0 4 

access-class 91 
exec-timeout 5 0 
login local 

transport input telnet 
accounting exec remoteacc 
exit 
aux 0 

transport input none 
login local 
exec-timeout 0 1 
no exec 
end 


The first thing to do when configuring access to a router is to setup the local access. 
The enable secret command sets the password on the priv ileged exec level and 
the username commands setup all the local accounts. Now when AAA is turned on 
the default authorization will not lock out the console. 


The message of the day should be used to provide the legal document for controlling 
access to the device and allowing for monitoring. This message should be generic 
and hopefully the same on all of your routers, firewalls, servers, workstations, etc. 

Next configure the security server and turn on AAA mechanisms. Since the shared 
secret to the RADIUS server is stored in the clear do not use the same shared secret 
for the router with any other device. Since communications to the security server are 
protected and the connection does not go outside the corporate boundary it is 
acceptable to allow communications to the server outside the router. 

With the aaa authentication login command make sure local is in the list as 
described earlier. Also, notice that the default accounting for exec is set to start-stop 
and that a named list was created for wait-start. This way by applying the named list 
to external connections and allowing the default list to automatically apply to console 
you will not be locked out of the router. Use connection accounting to track 
outbound connections generated by users logged onto the router, these should be 
minimal. 


Create and apply an access-list to the vty's to limit remote access to internal networks 
only and if possible limit the remote hosts by actual host IP addresses instead of a 
network address. Issue the login local command on the console and vty's incase 
AAA services get turned off. This will continue to allow limited remote access based 
upon the local database and will be ignored while AAA mechanisms are still running. 
Also limit remote access to telnet only and limit the connection idle time to 5 
minutes. The auxiliary port is disabled in this example. 
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If a TACACS+ server was used in this example instead of the RADIUS server then 
system accounting would have also been specified. Command level accounting 
could have been applied as well but would probably not be needed here. 

South Router Configuration: 

South(config) # enable secret rI^3r6Ed 

South(config) # username bethadmin password hsOoSTaG 

South(config) # username johnadmin password an0!h3r( 

South(config) # banner motd 

Aiji 

South(config) # tacacs-server host 14.2.6.18 
South(config) # tacacs-server key Ir3@lyh8n#w9@swD 

South(config) # aaa new-model 

South(config) # aaa authentication login default tacacst local 
South(config) # aaa accounting exec default start-stop tacacs+ 
South(config) # aaa accounting exec remoteacc wait-start tacacs+ 
South(config) # aaa accounting connection default start-stop 
tacacst 

South(config) # aaa accounting system default start-stop tacacst 
South(config) # aaa accounting commands 15 default stop-only 
tacacst 

South(config) # access-list 91 permit 10.2.1.0 0.0.0.255 log 
South(config) # access-list 91 deny any log 

South(config) # line con 0 

South(config-line) # transport input none 

South(config-line) # exec-timeout 5 0 

South(config-line) # login local 

South(config-line) # exit 

South(config) # line vty 0 4 

South(config-line) # access-class 91 

South(config-line) # exec-timeout 5 0 

South(config-line) # login local 

South(config-line) # transport input telnet 

South(config-line) # login authentication remotelist 

South(config-line) # accounting exec remoteacc 

South(config-line) # exit 

South(config) # line aux 0 

South(config-line) # transport input none 

South(config-line) # login local 

South(config-line) # exec-timeout 0 1 

South(config-line) # no exec 

South(config-line) # end 

As in the first example start by setting up local access to the router. The enable 
secret command sets the password on the privileged exec level and the username 
commands setup all the local accounts. In this case there may be fewer local 
accounts since this router is the first lines of defense to a secure enclave. Again, 
when AAA is turned on the default authorization will not lock out the console. 
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The Message of the Day should be used to provide the legal document for controlling 
access to the device and allowing for monitoring. This message should be generic 
and hopefully the same on all of your routers, firewalls, servers, workstations, etc. 

Next configure the security server and turn on AAA mechanisms. Since the shared 
secret to the TACACS+ server is stored in the clear do not use the same shared secret 
for the router with any other device. Since communications to the security server are 
protected and the connection does not go outside the corporate boundary it is 
acceptable to allow communications to the server outside the router. 

With the aaa authentication login command make sure local is in the list as 
described earlier. Notice that the default accounting for exec is set to start-stop and 
that a named list was created for wait-start. This way by applying the named list to 
external connections and allowing the default list to automatically apply to console 
you will not be locked out of the router. Use connection accounting to track 
outbound connections generated by users logged onto the router, these should be 
minimal. Also, include system and commands 15 accounting since this router is 
providing protection to a special enclave. 

As before, create and apply an access-list to the vty's to limit remote access to 
internal networks only and if possible limit the remote hosts by actual host IP 
addresses instead of a network address. Issue the login local command on the 
console and vty's incase AAA services get turned off. This will continue to allow 
limited remote access based upon the local database and will be ignored while AAA 
mechanisms are still mnning. Also limit remote access to telnet only and limit the 
connection idle time to 5 minutes. The auxiliary port is disabled in this example. 

If a RADIUS server was used in this example instead of the TACACS-i- server then 
system and command accounting would not be specified. 

4.6.3. Dial-In Users 

AAA services were designed with remote network access in mind. This includes 
remote access to routers as well as to network services like PPP. AAA using 
RADIUS is one of the primary means by which this is accomplished by Internet 
Service Providers (ISP's). Controlling access for dial-in users is similar to 
controlling access to the router but there are different protocols that are used. 
Additionally, although it is not shown, it is highly recommended that when dial-in 
access to the network or router is in use, that AAA services should be used in 
conjunction with a one-time password or similar token technology. Some important 
commands for controlling dial in users are: 


■ aaa authentication ppp {default | list-name} <method-list> IS 

used to specify PPP authentication method lists. 

" aaa authorization {network | exec | commands level | reverse- 
access} {default I list-name} <method-list> turns on AAA 
authorization for the specified type and designates the order in which 


Version l.Og 


UNCLASSIFIED 


153 





Router Security Configuration Guide 


UNCLASSIFIED 


authorization methods will be applied. In this case we are particularly 
interested in turning on network authorization. 

■ aaa accounting {system | network | exec | connection | 
commands level } {default | list-name] {start-stop | wait- 

start I stop-only I none} method-list tums On AAA's accounting 
services for the specified accounting type. For dial-in users network needs 
to be used. 

■ aaa processes number command is used to specify the number of 
background processes to start to handle concurrent authentication and 
authorization requests. 

■ (interface): ppp authentication {pap | chap | pap chap | chap 
pap) [if-needed] {default | list-name] [call-in] [one-tone] 
command is used to enable pap, chap, or both forms of authentication on 
the selected interface. 

■ (interface): ppp authorization {default | list-name] 
command is used to apply a ppp authorization list to the selected interface. 

■ (interface) : ppp accounting [default | list-name] command is 
used to apply accounting methods to the PPP service on the selected 
interface. 

The example below gives onE potential application of AAA services for dealing with 
dial-in services (Note: this example is not complete). Figure 4-9 shows the relevant 
portion of the network, and the configuration for East is shown after it. 
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East(config) # enable secret tltRd-lr 
East ( config) # username fredadmin password d$oyTldl 
East ( config) # username bethadmin password hs0o3TaG 
East ( conf ig) # banner motd ''T 


Aiji 

East(config) # radius-server host 14.2.6.18 
East(config) # radius-server i3dRc8sRv(@oeU4) 

East(config) # aaa new-model 

East(config) # aaa authentication login default radius local 

East ( config) # aaa authorization exec default radius 

East(config) # aaa authorization network default radius 

East(config) # aaa accounting exec default start-stop radius 

East(config) # aaa accounting exec remoteacc wait-start radius 

East(config) # aaa accounting connection default start-stop radius 

East(config) # aaa accounting network default wait-start radius 

East(config) # access-list 91 permit 14.2.9.0 0.0.0.255 log 

East(config) # access-list 91 permit 14.2.6.0 0.0.0.255 log 

East (config) # access-list 91 deny any log 

East(config) # line con 0 

East(config-line) # transport input none 

East(config-line) # exec-timeout 5 0 

East(config-line) # login local 

East(config-line) # exit 

East ( config) # line vty 0 4 

East(config-line) # access-class 91 

East(config-line) # exec-timeout 5 0 

East(config-line) # login local 

East(config-line) # transport input telnet 

East(config-line) # accounting exec remoteacc 

East(config-line) # exit 

East(config) # interface async 1 

East(config-if) # encapsulation ppp 

East(config-if) # ppp authentication chap 

East(config-if )# end 

In this example there are several items left incomplete: 1) the IPSec tunnel to Central 
has not been configured (see Section 5.2) to carry remote administrator access to the 
router (which is required to protect the username and password traveling across the 
facility backbone in the clear), 2) the terminal server lines have not been configured 
(and will need to have the remoteacc accounting list applied) and, 3) the 
asynchronous interface configuration needs completed (if the aux port is not used as 
an asynchronous interface disable it see Section 4.1.4). The following descriptions 
will only discuss items which are different from the Putting It Together examples in 
the previous section. 

AAA authorization for exec and network was added to separate the privileges for 
network users and router administrators. In addition, accounting was added for 
recording network events. The asynchronous interface contains the commands 
necessary for configuring AAA authentication for the ppp protocol. Also the AAA 
authorization and accounting default commands for network will aho apply to the 
ppp traffic as it traverses the line. 
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If a TACACS+ server was used in this example instead of the RADIUS server then 
system accounting would have also been specified. Command level accounting 
could have been applied as well but would probably not be needed here. 

This section only provides one example for a possible network access server 
configuration. Dealing with DiaUn Users is far to complex a subject to be dealt with 
in depth in this document. Please see Cisco's "Dial Solutions Configuration Guide" 
for more details. 

4.6.4. Security Server Protocols 

In Cisco routers and network access servers, AAA is the mechanism used to establish 
communications with security servers. Cisco supported security servers are 
RADIUS, TACACS+, and Kerberos. Security servers are important to Cisco 
network gear when centralized administration is required or when authorization and 
accounting services are needed. 


RADIUS 

Remote Authentication Dial In User Service (RADIUS) is an IETF proposed 
standard (RFC2865) for securing network components against unauthorized access. 
RADIUS is a distributed client/server based architecture used to pass security 
information between access points and a centralized server. RADIUS protects the 
communications using a shared secret. RADIUS can be used to provide 
authentication, authorization, and accounting services. RADIUS was designed with 
Dial In access control in mind and the accounting features are very flexible along 
these lines. However Cisco's RADIUS client does not support auditing of command 
or system events on the router or network access server. 

As a minimum when setting up a RADIUS server on a Cisco device the host address 
and shared secret must be configured as well as turning on and configuring AAA on 
the device. This is accomplished using the commands listed: 

■ radius-server host {hostname | ip-address} [auth-port 
port—number] [acct-port port-number] command specifies the 
radius server's hostname or IP address and the ports to use for 
authentication (authorization) and accounting. 

■ radius-server key string sets the RADIUS server shared 
encryption key. The shared secret key should be at least 16 characters 
long and follow the other rules for a good password as described in 
Section 4.1.4. 

For a complete list of RADIUS router configuration commands see the "RADIUS 
Commands" section in the "Security Command Reference". Simple example for 
Central: 

Central(config) # radius-server host 14.2.6.18 
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Central(config) # radius-server key W@t7a8y-2m@K3aKy 

RADIUS servers are freely available and are in extensive use. To perform 
authentication and authorization a RADIUS server uses attributes. These attributes 
can be configured to allow/deny access to various router and network services. For 
more details see the Security Configuration Guide on "Configuring RADIUS" and 
"RADIUS Attributes" sections for more details. 

TACACS+ 

Terminal Access Controller Access Control System plus (TACACS+) is the most 
recent Cisco security protocol designed to provide accounting and flexible control of 
authentication and authorization services. TACACS+ is implemented by Cisco using 
the AAA mechanisms and provides for the centralized validation of users using 
routers and network services. TACACS+ protects communications using a shared 
secret key between the network device and central server. TACACS+ was designed 
with Cisco implementations in mind so it offers a wide range of AAA services 
including full auditing of Cisco AAA accounting events. 

The primary commands used for configuring TACACS+ on a Cisco router are: 

■ tacacs-server host {hostname | ip-address} [port port- 
number} [key string] command can be used to specify the host, IP 
address or DNS name, where the TACACS+ server is running. The [port 
integer] can be used to specify a new port number. The [key string] sets 
the secret key for this TACACS+ server host overriding the default but 
should follow same creation rules as the default. 

■ tacacs-server key string command sets the default TACACS+ 
shared encryption key. The shared secret key should be at least 16 
characters long and follow the other rules for a good password as 
described in Section 4.1.4. 

For a complete list of TACACS+ router configuration commands see the "TACACS, 
Extended TACACS, and TACACS+ Commands" section in the "Security 
Command Reference". Simple example for Central: 

Central(config) # tacacs-server host 14.2.6.18 
Central(config) # tacacs-server key W@t7a8y-2m@K3aKy 

TACACS+ implementations are available through Cisco Secure ACS and Cisco also 
offers a free implementation as well. TACACS+ uses attribute-value pairs for 
controlling authentication and authorization services. These attribute-value pairs are 
configured on the server and used by the router authorization mechanism to control 
access to network services. For more details on the TACACS-i- and attribute-value 
pairs see the Security Configuration Guide sections "Configuring TACACS-t-" and 
'TACACS-i- Attribute-Value Pairs". 
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4.6.5. 


Kerberos 

Kerberos was developed by the Massachusetts Institute of Technology (MIT) and is 
an IETF standard (RFC 1510) as a network authentication system. Kerberos provides 
strong authentication for client/server applications by using secret-key cryptography. 
This mechanism can verify the identities of two users (i.e. person or network 
component) on unprotected networks. This authentication is performed using a 
tmsted third-party service using conventional (shared secret key) cryptography. In 
this system a client would request the credentials of the party they wish to contact 
from the trusted authentication service. The communications between all parties are 
encrypted using known secret keys or session keys issued from the authentication 
service. Kerberos can also be used to perform EXEC shell authorization using 
Kerberos Instance Mapping. After two users have been authenticated, Kerberos can 
be used to provide confidentiality and data integrity services. 

Kerberos infrastmctures are already in wide use. If you already have a Kerberos 
infrastmcture in place this may be the way to go. But note that Kerberos only allows 
for limited authorization capabilities and no accounting. There are freeware versions 
of Kerberos available as well as commercially supported products. Some more 
recent OS's come with Kerberos built-in. Examples using Kerberos are not covered 
in this guide but more details can be found in the Security Configuration Guide [1] 
section entitled “Configuring Kerberos”, and in RFC 1510. 
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4.7. Collected References 

The list below describes the major references and sources of information for the 
material presented here in Section 4. 

4.7.1. Books and Manuals 

Cisco Systems, lOS 11.3 Configuration Fundamentals , Cisco Press, 1998. 

Basic configuration guide for lOS 11.3, includes basic information on using 
the lOS command interface, basic lOS commands, and much more. 
Available in hardback form from Cisco Press, and on the Cisco 
Documentation CD. 

Cisco Systems, lOS 12.0 Configuration Fundamentals, Cisco Press, 1999. 

Basic configuration guide for lOS 11.3, includes basic i nf ormation on using 
the lOS command interface, basic lOS commands, and much more. 
Available in hardback form and on the Cisco Documentation CD. 

Cisco Systems, Cisco lOSNetwork Security, Cisco Press, 1998. 

This book is the security configuration manual and command reference for 
lOS 11.3. It includes extensive coverage of access management, AAA, and 
related topics. Also available on the Cisco Documentation CD as two 
separate documents: the “Security Configuration Guide” and the “Security 
Command Reference”. 

Cisco Systems, Cisco lOS 12.0 Network Security, Cisco Press, 1999. 

This book is the security configuration manual and command reference 
updated for lOS 12.0. It includes extensive coverage of access management, 
AAA, IPSec, and related topics. Also available on the Cisco Documentation 
CD as two separate documents: the “Security Configuration Guide” and the 
“Security Command Reference”. 

Held, G. and Hundley, K., Cisco Security Architectures, McGraw-Hill, 1999. 

This book includes excellent general advice about router and router-related 
network security, in addition to its Cisco-specific material. 

Held, G. and Hundley, K., Cisco Access List Field Guide, McGraw-Hill, 1999. 

Access lists are critical to most aspects of Cisco lOS security. This modest 
book is an extremely detailed, practical guide to creating access lists, and 
understanding access lists created by others. 

Innokenty, R., Cisco Routers for IP Routing: Little Black Book, Coriolis Group, 

1999. 
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This practical little book includes great practical advice on managing routes 
and routing protocols, mostly oriented toward lOS 11.2 and 11.3. 

Chappell, L. editor. Advanced Cisco Router Configuration, Cisco Press, 1999. 

Good coverage of advanced Cisco configuration issues, including extensive 
material on access lists and OSPF. 

Coulibaly, M.M., Cisco lOS Release: The Complete Reference, Cisco Press, 2000. 

Unbelievably detailed information on Cisco lOS release versions, the release 
management process, features in releases, and upgrade paths. 

McGinnis, E. and Perkins, D., Understanding SNMP MIBs, Prentice-Hall, 1996. 

A detailed exploration of the SNMP management information base, 
including both standard and vendor-specific structures. 


4.7.2. Articles and Papers 

“Increasing Security on IP Networks” Cisco Internetworking Case Studies, 1998. 
available at: http : / /www . cisco . com/univercd/cc/td/doc/cisintwk/ics/ 

An old but useful article on using a Cisco router to protect a network 
boundary. Includes some coverage of access lists and passwords. 

“Improving Security on Cisco Routers”, Cisco Security Advisories, 2000. 
available at: http : / / www .cisco . com/warp/public/7 0 7/21. html 

A good overview article on tightening up the security on a typical Cisco 
router mnning lOS 11.3 or later. 

“Unicast Reverse Path Forwarding”, Cisco lOS 1 l.l(CC) Release Notes, Cisco 
Systems, 2000. 

available at: http : / /www . cisco . com/univercd/cc/td/doc/product / 
software/ioslll/cclll/uni_rpf.htm 

Initial documentation on unicast reverse-path forwarding verification, 
includes a good explanation of the concepts. 
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5. Advanced Security Services 

This section describes some Cisco lOS facilities that are not central to the task of 
securing a router. These facilities offer additional security services that can 
contribute to the secure operation of entire networks or communities. 


5.1. Role of the Router in Inter-Network Security 

When considering the task of joining IP security with IP router functionality, the 
network administrator (NA) or security engineer (SE) can be overwhelmed. The vast 
amount of available literature and the technical jargon can cause the SA to ignore 
available security features altogether. To reduce this daunting task to one which is 
manageable and easily understandable, this section of the guide will focus on the 
concept of “packet protection”. Each packet passing through, or created by the router 
has source addresses and is carrying data which may need some form of protection. 
By focusing on this fundamental building block of IP networking, we can devote our 
energy to providing you with some basic cryptographic concepts, and the specific 
Cisco lOS commands that implement them. These can then be easily incorporated 
into current router configurations to help meet specific security requirements. 

Routers used for supplying packet protection are almost always positioned as 
gateway devices. These devices sit between untmsted networks, such as the Internet, 
and local tmsted networks. In 1996, Cisco released lOS version 11.2, which included 
the Cisco Encryption Technology (CET). This proprietary solution was a stopgap 
effort for customers until a standards-based solution was in place. While it provided 
some level of packet protection for Cisco-to-Cisco communications, it did not allow 
Cisco products to interoperate with other IP security products. Since the adoption of 
the lETE IP Security (IPSec) standards, both Cisco (in lOS 11.3 and above) and other 
IP product manufacturers have implemented and offered IPSec solutions for packet 
protection to their customers. This standards-based approach allows for 
interoperability between Cisco routers and other IP security products, e.g. non-Cisco 
routers, firewalls, etc. Thus, IPSec tunnels can be constmcted between two routers’ 
interfaces using the IPSec protocol framework. This framework has been scrutinized 
by many skilled evaluators in industry and academia. It works in conjunction with the 
standards-based Internet Key Exchange (IKE) protocol to provide the users a very 
solid IP security foundation. 
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5.2. IP Network Security 

Prior to establishing an IPSec configuration on the router, certain network and current 
router configuration checks should be made to eliminate any router connectivity 
problems. Since IPSec utilizes IP protocols 50 and 51, and the User Datagram 
Protocol (UDP) port 500 in its communications, any access list restrictions on these 
ports or protocols should be removed or changed to allow the IPSec packets to be 
transmitted and received by the participating routers. The example below illustrates 
the ACL rule syntax for permitting incoming IPSec traffic. 

access-list 100 permit 50 host 7.12.1.20 host 14.2.0.20 

access-list 100 permit 51 host 7.12.1.20 host 14.2.0.20 

access-list 100 permit udp host 7.12.1.20 host 14.2.0.20 eq 500 

Also, the routers may be configured using several different modes of operation. For 
the example in this section, we assume the routers have two modes of operation: 
basic mode and privileged EXEC mode. In the basic mode of operation, anyone with 
access to the router can view selected information about the current mnning 
configuration. In the privileged EXEC mode, the administrator can update and/or 
change the current mnning configuration. Eor more information about command 
modes, see Section 4.1. 

The security guidance of this section does not exhaustively cover all IPSec options. 
Rather, it provides a set of options (e.g. which algorithms to use) and the appropriate 
Cisco lOS commands to implement them in an easy-to-follow, step-by-step example 
for helping you set up and test IPSec on your network. In the example that follows, 
the external interfaces of the North router, 14.2.0.20, and the Remote router, 

7.12.1.20, will be used to help demonstrate the concepts (see Eigure 4-1). 

5.2.1. Building IPSec Tunnels 

Building IPSec tunnels between two Cisco routers will involve entering three sets of 
information into each router’s mnning configuration files. The sets can be labeled as: 

1. Establishing a common IKE Authentication Key 

2. Establishing an IKE Security Policy 

3. Establishing the IPSec Protection Parameters 

Establishing a Common IKE Authentication Key 

Prior to establishing an IPSec tunnel between two routers, each router must determine 
exactly which IP address they are building the tunnel with. This authentication 
decision is made in the IPSec framework using the IKE protocol. While IKE has 
several ways it can authenticate the two routers to each other, we will only discuss 
how it uses a jointly held secret value (i.e. a pre-shared key) to do it. However, for 
operational security we HIGHLY recommend that IKE authentication decisions be 
made using IPSec authentication schemes in conjunction with digital certificates. 
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Consult the Cisco lOS 12.0 Security Configuration Guide [2] for details on the other 
IKE options. 

(Note: the router used for part of this example is named “Remote”, and that name 
appears in all the prompts. Do not use a remote administration connection to enter 
sensitive IPSec parameters - use a local console connection.) 

To use pre-shared keys for making authentication decisions in IKE, each router must 
possess the same secret key. These keys should be obtained out-of-band by each of 
the routers’ administrators. Once the keys are securely held, the network 
administrators for the North and Remote routers (possibly the same person) should 
enter the key into their routers. For this example, the secret key is “01234abcde”. We 
strongly recommend using difficult-to-guess combinations of characters, numbers, 
and punctuation symbols to build operational pre-shared keys. To enter the keys, use 
the crypto isakmp command in global configuratbn mode, as shown below. 

The syntax for the crypto isakmp command is: crypto isakmp key key-value 
address destination-ip-address. 


North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
North(config)# crypto isakmp key 01234abcde address 7.12.1.20 

North(config)# exit 
North# 


and 


Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config)# crypto isakmp key 01234abcde address 14.2.0.20 

Remote(config)# exit 
Remote# 


When entering new configuration information into the router it is always a good idea, 
after entering the new information, to check and see if the router has received the 
intended configuration information. One way to verify that the pre-shared keys were 
properly entered is to display the router’s mnning-configuration and look for the pre¬ 
shared key entered above. This can be done using the show running-conf ig 
command in privileged EXEC mode. 

Establishing an IKE Security Policy 

Each router contains a list of IKE security polices. In order for two routers to be 
interoperable, there must be at least one policy in common between them. These 
policies capture information needed by the IKE protocol to help build a secure IPSec 
tunnel between the two routers. Each necessary parameter for the policy is listed 
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below with a short description of its purpose (the default setting is given first in all 
lists of choices): 


■ priority number - a positive integer used to uniquely identify the policy 
when two or more are contained within the routers configuration file 
(default: none) 

■ encryption algorithm - for protecting the IKE protocol messages (choices: 
DBS, 3DES in certain lOS versions, e.g. 12.0(3)T). Unless you have a very 
sound reason to use DES, (e.g. 3DES doesn’t provide the needed 
performance) always use 3DES. The DES algorithm is not acceptable, 
however, to protect information between two peers over a hostile, 
unprotected network (e.g. the Internet), so use 3DES for such cases. 

■ hash algorithm - for providing integrity to IKE protocol messages 
(choices: SHA, MD5) 

■ authentication method - for identifying the routers attempting to establish 
a tunnel (choices: Rivest-Shamir-Adelman (RSA) signature, RSA 
encryption, pre-shared keys) 

■ P if fle -Heilman group - used for computing the encryption key (choices: 

#1 (768 bit modulus), #2 (1024 bit modulus)). We recommend using #2, 
and eventually #5 (1536 bit modulus) when it becomes available. 

■ security association lifetime - lifetime (in seconds) a tunnel should remain 
in place before it is automatically rebuilt (default: 86400 (one day)) 


The administrators for the North and Remote routers should enter the IKE security 
policy into their routers using the following commands shown below. 


North# 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# crypto isakmp policy 1 

! The policy number may be an integer between 1 and 65,536, with 
! the priority given to lower numbers 
North(crypto-isakmp)# encryption 3des 

If the user's version of the lOS only supports the DES 
algorithm, and community of interest data separation is needed, 
then use the following command to select DES for encryption 
North(crypto-isakmp)# encryption des 
North(crypto-isakmp)# hash sha 

North(crypto-isakmp)# authentication pre-share 

North(crypto-isakmp)# group 2 

North(crypto-isakmp)# lifetime 86400 

North(crypto-isakmp)# exit 

North(config)# exit 

North# 


and 
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Remote# 

Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config) # crypto isakmp policy 1 

! The policy number may be an integer between 1 and 65,536, with 
! the priority given to lower numbers 
Remote(crypto-isakmp)# encryption 3des 

! If the user's version of the lOS only supports DES, and 
! community of interest data separation is needed, then use the 
! following command to select DES for encryption 
! Remote(crypto-isakmp)# encryption des 
Remote(crypto-isakmp)# hash sha 

Remote(crypto-isakmp) # authentication pre-share 

Remote(crypto-isakmp)# group 2 
Remote(crypto-isakmp)# lifetime 86400 
Remote(crypto-isakmp)# exit 
Remote (config)# exit 
Remote# 


Using the show crypto isakmp policy command in privileged EXEC mode (on 
either Remote or North) should now display the following information: 

North# show crypto isakmp policy 

Protection suite of priority 1 

encryption algorithm: 3DES - Triple Data Encryption Standard (168 
bit keys) 

hash algorithm: Secure Hash Standard 

authentication method: Pre-Shared Key 
Diffie-Hellman group: #2 (1024 bit) 

lifetime: 86400 seconds, no volume limit 

Default protection suite 

encryption algorithm: DES - Data Encryption Standard (56 bit 
keys) 

hash algorithm: Secure Hash Standard 

authentication method: Rivest-Shamir-Adleman Signature 
Diffie-Hellman group: #1 (768 bit) 

lifetime: 86400 seconds, no volume limit 

North# 


Establishing the IPSec Protection Parameters 

Using the pre-shared key and the security policy, IKE will determine preliminary 
information needed to create IPSec tunnels. We now need to give the tunnel its 
desired characteristics. This parameter set can be built using the following three 
steps: 

1. Creating the appropriate access lists 
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Some administrators will want to create tunnels to protect all protocol data flowing 
between two routers. Others will desire to protect only a subset of the data flow (e.g. 
all telnet, ftp, and http traffic). The following example displays an access list needed 
to protect ALL protocol information between the North and Remote routers. Using 
the any option (e.g. access-list 161 below) for both the source and destination in the 
access list will force all packets to be IPSec protected. Choosing the any option for 
the source and destination also eliminates the need for netmasking in the access list. 
Access lists can be used to improve the granularity of the IPSec tunnels, see Section 
4.3 to learn more about access lists. 


The syntax for an access list rule, somewhat simplified, is shown below. 

access-list access-list-number {deny | permit} protocol 
source source-wildcard source-options 
destination destination-wildcard destination-options 
auditing-options 

The network administrator for the North and Remote routers should enter the IPSec 
access list into their routers using the following commands in privileged EXEC 
mode: 


North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
North(config)# access-list 161 permit ip any any log 

North(config)# exit 
North# 


and 


Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config)# access-list 161 permit ip any any log 

Remote(config)# exit 
Remote# 


2. Configure the appropriate transform set 

The Cisco transform set identifies the desired protection mechanisms for building the 
IPSec tunnel. If the tunnel needs data authentication protection, then choosing either 
the Authenticated Header (AH) or the Encapsulated Security Payload (ESP) IPSec 
protocols with either hashing algorithms SHA or MD5 will suffice. If the tunnel you 
are setting up needs data confidentiality protection, then choose the ESP protocol 
with either the DES or 3DES encryption algorithms (we highly suggest 3DES). A 
network administrator could argue that data authentication is not really needed for a 
protective tunnel between gateway routers since this property is normally obtained by 
an application behind the router which is pushing data through the tunnel, but adding 
it can improve defense in depth. In the following example, the ESP protocol is 
chosen with both data protection and authentication properties applied to all 
information transmitted between the North and Remote routers. 
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The transform set also specifies what part of each packet is protected by the IPSec 
tunnel. For a hostile network scenario, the preferred mode is tunnel (which is the 
default). This mode protects both the original data portion of the IP packet and the 
original packet header, and creates a new IP header using the routers’ IP addresses. 
This hides potentially sensitive IP protocol information about the networks and 
applications that are sending data through the tunnel. If the IPSec tunnel is used for 
separating communities of interest over a protected network, then the transport mode 
will be sufficient. This mode protects the original data portion of the IP packet, but 
leaves the original IP header intact. The IPSec standards requires that tunnel mode be 
used when routers are employed as gateway security devices. For more information 
on both the encryption and authentication algorithms, and the tunnel modes, consult 
the Cisco lOS 12.0 Security Configuration Guide [2]. 

The command syntax for configuring an IPSec transform set is: crypto ipsec 
transform-set transform-set-name transforml transformf . . . 

transformN. When you give this command, lOS will enter crypto transform set 
configuration mode, to which you can give a variety of transform-set related 
commands. Use exit to leave transform set configuration mode. 

Configure the IPSec transform sets using the following commands: 

North# 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# crypto ipsec transform-set setl esp-3des esp-sha-hmac 

! The name setl is an arbitrary name 

North(cfg-crypto-trans)# mode tunnel 

North(cfg-crypto-trans)# exit 

North(config)# exit 

North# 


and 


Remote# 

Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

Remote(config) #crypto ipsec transform-set setl esp-3des esp-sha-hmac 

! The name setl is an arbitrary name 
Remote(cfg-crypto-trans)# mode tunnel 
Remote(cfg-crypto-trans)# exit 
Remote(config)# exit 
Remote# 


3. Create the necessary crypto map 

Cisco lOS uses crypto maps to bring together all information needed to create IPSec 
tunnels. This information includes: the access-list to specify what traffic should be 
protected (covered above in section 1), the transform-set used to build the tunnel 
(covered above in section 2), the remote address for the peer end of the IPSec tunnel, 
the security association lifetime for the tunnel (in kilobytes and/or seconds), and 
whether to use the IKE protocol in setting up the tunnel. Each crypto map is 
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identified by a map-name and a positive integer sequence number (called seq-num 
below). The map-name used can represent one or more crypto maps, while the 
sequence numbers are used to set the priority for two or more crypto maps with the 
same name. If two or more crypto maps with the same name are used, those with 
lower the sequence numbers have higher priority. The following example shows the 
construction of a single crypto map for the North and Remote routers, which combine 
the previously entered configuration information. See “Configuring IPSec Network 
Security” in the Cisco lOS 12.0 Security Configuration Guide to learn more about 
crypto maps. The syntax for the crypto map command is: crypto map map-name 
seq-num ipsec-isakmp. 


Configure the IPSec crypto maps using the following commands: 


North# 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
North(config)# crypto map pipe-1 1 ipsec-isakmp 

! The name pipe-1 is an arbitrary name 

North(config-crypto-map)# match address 161 

North(config-crypto-map)# set peer 7.12.1.20 

North(config-crypto-map)# set transform-set setl 

! The following are optional, they limit the length of time and 

! number of bytes the tunnel is good for data protection before 

! automatic rekeying occurs 

North(config-crypto-map)# set security-assoc lifetime kilo 80000 
North(config-crypto-map)# set security-assoc lifetime sec 26400 

North(config-crypto-map)# exit 

North(config)# exit 

North# 


and 


Remote# 

Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config) # crypto map pipe-1 1 ipsec-isakmp 

! The name pipe-1 is an arbitrary name 

Remote(config-crypto-map)# match address 161 

Remote(config-crypto-map)# set peer 14.2.0.20 

Remote(config-crypto-map)# set transform-set setl 

! The following are optional, they limit the length of time and 

! number of bytes the tunnel is good for data protection before 

! automatic rekeying occurs 

Remote(config-crypto-map)# set security-assoc lifetime kilo 80000 
Remote(config-crypto-map)# set security-assoc lifetime sec 26400 

Remote(config-crypto-map)# exit 

Remote(config)# exit 

Remote# 

The command show crypto map will display the following information on the 
North router (assuming no other crypto maps have been entered): 
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North# show crypto map 

Crypto Map "pipe-1" 1 ipsec-isakmp 
match address 101 
peer 7.12.1.20 
set transform-set setl 

set security-association lifetime kilobytes 80000 
set security-association lifetime seconds 26400 
North# 


Turning on IPSec at the Appropriate Interface 

Once the previous steps have been completed, we are almost ready to build a tunnel 
between the North and Remote routers. As a quick check (which could potentially 
eliminate many headaches) before turning on IPSec, make sure the two routers are in 
a state where they can communicate (i.e. without an IPSec tunnel). A simple ping 
7.12.1.20 on North should, in all likelihood, give us this answer. Assuming the 
ping was successful, we are now ready to build a tunnel between our routers. If both 
routers are connected to the Internet, as in figure 4-1, using outside interface ethO/0, 
then the following commands should prepare both routers to establish an IPSec 
tunnel at the first beckoning of an IP packet which matches access lists 161. 


North# 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# interface ethernet 0/0 

North(config-if)# crypto map pipe-1 

North(config-if)# exit 

North(config)# exit 

North# 


and 


Remote# 

Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config)# interface ethernet 0/0 

Remote(config-if)# crypto map pipe-1 
Remote(config-if)# exit 
Remote(config)# exit 
Remote# 


If IPSec is no longer needed to protect traffic between two routers, then remove the 
crypto maps from the interfaces which they were applied, as shown below. 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

North(config)# interface ethernet 0/0 
North(config-if)# no crypto map pipe-1 

North(config-if)# end 
North# 
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and 


Remote# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
Remote(config)# interface ethernet 0/0 

Remote(config-if)# no crypto map pipe-1 
Remote(config-if)# exit 
Remote(config)# exit 
Remote# 


Testing 

A quick way to test if our IPSec tunnel has been established between the two routers 
is to simply execute a ping from one router to the other. If everything has been set up 
properly, the access lists will have notified the lOS that an IPSec tunnel has been 
requested to protect packet data. This will cause the routers to use the IKE protocol 
(including the IKE authentication key and the IKE security policy information) for 
authenticating the two routers and facilitate the negotiation of the IPSec tunnel’s 
protection algorithms (i.e. the transform set). If the negotiation is successful, the 
tunnel will be established and the ping requests will be protected. Depending on the 
time allotted for a ping echo reply to return to the ping source, the first ping requests 
might time out since the computation time needed for the IKE key exchange / IPSec 
computations varies depending on the size of the router, speed of the network, etc. 

Once the IPSec tunnel has been established, the user should be able to review the 
IPSec tunnel parameters. These parameters can be seen using the show crypto 
ipsec security-association and the show crypto isakmp security- 
association commands. 


North# show crypto isakmp security-association 

dst src state conn-id slot 

7.12.1.20 14.2.0.20 QM_IDLE 1 0 

North# show crypto ipsec security-association 

interface: EthernetO 

Crypto map tag: pipe-1, local addr. 14.2.0.20 

local ident (addr/mask/prot/port): 
(14.2.0.20/255.255.255.255/0/0) 

remote ident (addr/mask/prot/port): 
(7.12.1.20/255.255.255.255/0/0) 
current_peer: 17.12.1.20 

PERMIT, flags={origin_is_acl, } 

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest 5 
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify 5 
#send errors 5, #recv errors 0 

local crypto endpt.: 14.2.0.20 
remote crypto endpt.: 7.12.1.20 
path mtu 1500, media mtu 1500 
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current outbound spi: 1B908AE 

inbound esp sas: 
spi: 0XEFA038E(251265934) 

transform: esp-3des esp-sha-hmac , 

in use settings ={Tunnel, } 

slot: 0, conn id: 2, crypto map: pipe-1 

sa timing: remaining key lifetime (k/sec): (4607999/3459) 

IV size: 8 bytes 

replay detection support: Y 


inbound ah sas: 


outbound esp sas: 
spi: 0xlB908AE(28903598) 

transform: esp-3des esp-sha-hmac , 

in use settings ={Tunnel, } 

slot: 0, conn id: 3, crypto map: pipe-1 

sa timing: remaining key lifetime (k/sec): (4607999/3459) 

IV size: 8 bytes 

replay detection support: Y 


outbound ah sas: 


Troubleshooting 

Most current IPSec implementations, including Cisco’s, can be very temperamental. 
If any one of many parameters are not set properly, the constmction of the IPSec 
tunnel will not succeed. And even when a tunnel is established, a few Cisco lOS 
releases have demonstrated unstable functionality: in some cases packets which 
should be protected by the tunnel are passed in the clear. 

If your routers do not correctly establish the IPSec tunnels that you need, the 
following suggestions will help reset the IPSec relevant router parameters and 
hopefully allow for a tunnel to be constructed. 

1. Re-initialize the IPSec parameters by removing the IPSec and IKE security 
associations 

When an attempt is made to construct an IPSec tunnel between two peers, the lOS 
stores certain information about both of their IPSec configuration files. If the tunnel 
fails to be constmcted, this information will reside in lOS memory and hinder future 
attempts at constmcting tunnels between these two peers. To remove this information 
and allow the routers to begin a fresh IPSec negotiation of tunnel parameters, several 
things can be done. First, if the crypto maps are removed from the interfaces where 
they were placed (e.g. interface ethO/0 on both North and Remote above), then the 
information will be removed. If the crypto maps are in use by established tunnels, 
then removing them is not a viable option. Hence, several commands may be used to 
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collectively remove the unwanted information. The EXEC mode commands clear 
crypto sa or clear crypto isa commands, and the global configuration mode 
command no crypto ipsec sa, all tailored to the specific peer devices involved, 
will remove the unwanted information. 

2. Make sure the routers have m ir ror access lists 

The Cisco lOS IPSec code can get easily confused when the access lists, which are 
engaged by the crypto maps to determine what packets are protected using the IPSec 
tunnel, are not m ir ror images of each other. In our example above, we can see that the 
access lists used by both North and Remote are m ir ror images since they both involve 
using the any option to indicate that all protocol packets, with source and destination 
addresses each behind one of the routers, get protected. On the other hand, if we only 
want to protect packets to/from a LAN behind the Remote router (IP address 
7.0.0.1/24) with anyone behind the East router (IP address 14.2.1.20/16), then the 
following access lists on Remote and North would satisfy the mirror access list 
requirement and should allow for the tunnel to be constmcted between North and 
Remote. 

On North: 

access-list 101 permit ip 14.2.1.20 0.0.255.255 7.0.0.1 0.0.0.255 
On Remote: 

access-list 102 permit ip 7.0.0.1 0.0.0.255 14.2.1.20 0.0.255.255 

3. Turning on the debug commands to observe the router’s IPSec negotiation 

It can be very helpful to mn both the debug crypto ipsec and the debug crypto 
isakmp commands, which can be entered while the router is in privileged EXEC 
mode. (Note: If the routers establishing the IPSec tunnel are not currently 
operational, turning on full debugging using the debug all command supplies even 
more diagnostic information. Pull debugging imposes too great a load to be practical 
for operational routers.) The debugging messages will allow the network 
administrator to observe how the local router is processing the remote router’s IPSec 
packets during the tunnel negotiation, and determine exactly where the negotiations 
are failing. Below is a list of the North router’s output when these two debug 
commands were turned on. (Note: These debug options were mn at different times, 
but both were on while the IPSec tunnel was being constmcted.) 


North# debug crypto isakmp 

Crypto ISAKMP debugging is on 

North# ping 7.12.1.20 


Type escape sequence to abort. 

Sending 5, 100-byte ICMP Echos to 7.12.I.20, timeout is 2 seconds: 

I I I I 


Success rate is 80 percent (4/5), round-trip min/avg/max = 
32/33/36 ms 
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North# 

00:19:35: 

405257172 

00:19:35: 

00:19:35: 

00:19:35: 

405257172 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

0x0 

00:19:35: 

00:19:35: 

00:19:35: 

405257172 

00:19:35: 

405257172 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 

00:19:35: 


ISAKMP 

(1) 

: beginning Quick Mode exchange. 

M-ID of 

ISAKMP 

(1) 

: sending packet to 7.12.1.29 (I) 

QM_IDLE 

ISAKMP 

(1) 

: received packet from 7.12.1.20 

(I) QM_IDLE 

ISAKMP 

(1) 

: processing SA payload, message 

ID = 

ISAKMP 

(1) 

: Checking IPSec proposal 1 


ISAKMP 

transform I, ESP_3DES 


ISAKMP 


attributes in transform: 


ISAKMP 


encaps is 1 


ISAKMP 


SA life type in seconds 


ISAKMP 


SA life duration (basic) of 3600 

ISAKMP 


SA life type in kilobytes 


ISAKMP 


SA life duration (VPI) of 0x0 

0x46 0x50 

ISAKMP 


authenticator is HMAC-SHA 


ISAKMP 

(1) 

: atts are acceptable. 


ISAKMP 

(1) 

: processing NONCE payload, message ID = 

ISAKMP 

(1) 

: processing ID payload, message 

ID = 

I SAKMP 

(1) 

: Creating IPSec SAs 



inbound SA from 7.12.1.20 to 14.2.0.20 
(proxy 7.12.1.20 to 14.2.0.20 ) 

has spi 59056543 and conn_id 4 and flags 4 
lifetime of 3600 seconds 
lifetime of 4608000 kilobytes 
outbound SA from 14.2.0.20 to 7.12.1.20 
(proxy 14.2.0.20 to 7.12.1.20 ) 

has spi 595658916 and conn_id 5 and flags 4 
lifetime of 3600 seconds 
lifetime of 4608000 kilobytes 
ISAKMP (1): sending packet to 7.12.1.20 (I) QM_IDLE 


North# no debug all 


North# debug crypto ipsec 

Crypto IPSEC debugging is on 

North# ping 7.12.1.20 

North# 

4w0d: IPSEC(validate_proposal_request): proposal part #1, 
(key eng. msg.) dest= 7.12.1.20, src= 14.2.0.20, 
dest_proxy= 7.12.1.20/255.255.255.255/0/0 (type=l), 
src_proxy= 14.2.0.20/255.255.255.255/0/0 (type=l), 
protocol= ESP, transform= 3esp-des esp-sha-hmac , 
lifedur= Os and Okb, 

spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 
4w0d: IPSEC(key_engine): got a queue event... 

4w0d: IPSEC(spi_response): getting spi 595658916 for SA 
from 14.2.0.20 to 7.12.I.20 for prot 3 
4w0d: IPSEC(key_engine): got a queue event... 

4w0d: IPSEC(initialize_sas): , 
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(key eng. msg.) dest= 7.12.1.20, src= 14.2.0.20, 
dest_proxy= 7.12.1.20/255.255.255.255/0/0 (type=l), 
src_proxy= 14.2.0.20/255.255.255.255/0/0 (type=l), 
protocol= ESP, transform= 3esp-des esp-sha-hmac , 
lifedur= 3600s and 4608000kb, 

spi= 0x238108A4(595658916), conn_id=100, keYsize=0,flags=0x4 
4w0d: IPSEC(initialize_sas): , 

(key eng. msg.) dest= 7.12.1.20, src= 14.2.0.20, 
dest_proxy= 7.12.1.20/255.255.255.255/0/0 (type=l), 
src_proxy= 14.2.0.20/255.255.255.255/0/0 (type=l), 
protocol= ESP, transform= 3esp-des esp-sha-hmac , 
lifedur= 3600s and 4608000kb, 

spi= 0x385219F(59056543), conn_id=101, keYsize=0, flags=0x4 
4w0d: IPSEC(create_sa): sa created, 

(sa) sa_dest= 7.12.1.20, sa_prot= 50, 
sa_spi= 0x238108A4(595658916), 

sa_trans= 3esp-des esp-sha-hmac , sa_conn_id= 100 
4w0d: IPSEC(create_sa): sa created, 

(sa) sa_dest= 7.12.1.20, sa_prot= 50, 
sa_spi= 0x385219F(59056543), 

sa_trans= 3esp-des esp-sha-hmac , sa_conn_id= 101 
North# no debug all 


4. Use an IP packet sniffer to observe the contents of each packet in the IPSec 
tunnel negotiation 

This information, like that obtained from mnning the debug commands on the router, 
is invaluable in diagnosing exactly where the tunnel negotiation is failing, and for 
recovering from failures. 


5.2.2. Using IPSec for Secure Remote Administration 

The example used throughout the preceding section was to securely connect two 
networks from theh gateways (which were Cisco routers). This could represent 
either connecting widely separated networks, or isolating networks within an 
organization. Another use of IPSec would be to use it to protect the administration of 
a Cisco router. Common ways to perform administration of a Cisco router is to use 
either a telnet (which sends the password in the clear) or SN MP. Since both of these 
mn over IP, IPSec can be used to encrypt this communication, eliminating the threat 
of a network sniffer seeing either the password being sent across the network or the 
current configuration. 

In this example, a computer on the desk of the administrator is to be used to 
administer the North router. Let’s say the computer the administrator uses to 
configure the router has IP address 14.2.9.6, which is next to the servers in Figure 4- 
1. The IP address of the North router on the interface closest to the administrator is 
14.2.1.250, so we’ll secure a connection to there. First, we’ll set up the configuration 
on the router, then examine the configuration sequence for a PC mnning Microsoft 
Windows 2000. 
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Configuring the Cisco Router for Secure Remote Administration 

On the Cisco router, perform the following steps: 

1. Enter configuration mode: 

North# config t 

Enter configuration commands, one per line. End with CNTL/Z. 
North(config)# 

2. Enable telnet access to the router for administration from the administrator’s 
machine. We’ll use access list 12 to list the machines that may to telnet to the router. 

North(config)# no access-list 12 

North (config)# access-list 12 permit 14.2.9.6 

North (config)# vty 0 4 
North(config-line) access-class 12 in 
North(config-line) exit 
North(config)# 

3. Create an ISAKMP policy. The policy number selected here is 10, which is just an 
arbitrary number to set a priority, if two or more ISAKMP policies exist on North. 
Since the authentication is only between 2 machines, certificates just for this 
probably aren’t warranted, and so pre-shared keys can be used. Pre-shared keys are 
passwords - or better yet a passphrase. However, if some form of a PKI is already in 
place, certificates certainly can be used. The encryption options are DES and 3DES, 
and DES has been demonstrated to be very weak, and possibly not even strong 
enough to protect passwords, so we recommend 3DES. The key exchange size of 
group 2 is larger than that for group 1, so again we select the stronger option. The 
default hashing algorithm, SHA, is suitable, so we will take the default and not enter 
it. The other option is the lifetime until a key renegotiation is required, but again, this 
does not concern us too much, so we will skip this. 

North(config)# crypto isakmp policy 10 

North(config-isakmp)# authentication pre-share 

North(config-isakmp)# encryption 3des 
North(config-isakmp)# group 2 
North(config-isakmp)# exit 
North(config)# 

4. Type in the authentication password. Please do not use anything in the dictionary, 
or anything easily guessed; include letters, numbers, and punctuation. 

North(config)# crypto isakmp key my4pa$$phra$eHere 
address 14.2.9.6 

5. The transform-set contains the parameters for protecting the actual traffic. Again, 
we want to use 3DES, and SHA. Since we are treating the router as just a host to 
connect to (i.e. it is not forwarding this particular traffic anywhere else), we can use 
transport mode instead of tunnel mode. This choice is also made because currently it 
is easier to configure IPSec in Windows 2000 to use transport mode. 
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North(config) # crypto ipsec transform-set 

3des-sha-xport esp-3des esp-sha-hmac 

North(cfg-crypto-trans) # mode transport 
North (cfg-crypto-trans) # exit 
North(config)# 

6. The IPSec connections must be allowed. We number the access-list as 167. 

North(config) # access-list 167 permit ip host 14.2.1.250 
host 14.2.9.6 log 

7. A crypto map must be created. Any name can be given to this - we use cisco- 
admin. Priority for this crypto map is set to 10. The match address links the desired 
access-lists to the crypto map, so we use the one we entered in the previous step, 167. 

North(config) # crypto map cisco-admin 10 ipsec-isakmp 

North(config-crypto-map) # set peer 14.2.9.6 

North(config-crypto-map) # set transform-set 3des-sha-xport 

North(config-crypto-map) # match address 167 
North(config-crypto-map) # exit 
North(config)# 

8. Finally, apply these definitions to the interface (the 14.2.1.250 interface is named 
Ethernet 0/0). When doing so, weTl ensure that no other crypto maps are still in 
existence before we define this one. Then we exit from configuration mode, and 
IPSec should be running on the Cisco router. 

North(config) # interface ethernet 0/0 

North(config-if) # no crypto map 

North(config-if) # crypto map cisco-admin 

North(config-if )# exit 
North (config) # exit 
North# 

Configuring Windows 2000 for Secure Remote Administration 

Once the Cisco router has been set up, the Windows 2000 computer on the desktop of 
the administrator can be prepared. This section assume moderate familiarity with 
Windows 2000 network administration. 

First, mn Microsoft Management Console (MMC), either from a command window 
prompt, or by using the “Run” command from the “Start” menu). “Add” the IPSec 
snap-in for the local machine. You can add the snap-in by looking under the 
“Console” menu and selecting “Add/Remove Snap-in”. That will give you a window 
containing the currently added list of snap-ins, initially empty. Click the “Add” 
button and you will see all the possible snap-ins. Scroll down until you see one titled 
“IPSec Policy Management” and select that one. It will ask which computer it should 
manage, and select “Local Computer”, click “Finish”, “Close” the list of additional 
snap-ins, and “OK” the one snap-in that you have added. The management console 
window should now look something like the screenshot below. 
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Click right on “IP Security Policies on Local Machine” (either the left or right 
window will work) and select “Create IP Security Policy”. A wizard shows up to 
assist you on this quest. Click “Next”. It asks for a name and description for this 
new policy. Any name will do, perhaps something like “Admin to Router”, and you 
aren’t required to fill in a description. Click “Next”. Click so that the default 
response rule is not activated, click “Next”. In this window, ensure that the “Edit 
properties” box is selected, and then hit the “Finish” button. The following window 
should appear. 


Admin to Cisco Properties 


Rules I General | 


^3 


Security rules for communicating with other computers 


llJSi 


P Security Rules; 

IP Filter List 

1 Filter Action 

1 Authentication... 

|Tu 

QkDynamio 

Default Response 

Kerberos 

Nc 


_I li 

Add... I Edit... I Remove | p Use Acid WizarcJ 


Cancel 


Two things must be done in this window. A new rule must be added, for which we 
will use the Add Wizard, which we will do in a second, but before that, we will 
configure the key exchange parameters (which were called by the name isakmp in the 
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Cisco configuration). In the tabs at the top of this window, select “General”. Under 
that tab at the bottom of the screen is a button for “Key Exchange using these 
settings” with the word “Advanced” written on the button. Click that. The window 
that appears contains the title “Key Exchange Settings”. 



In this window, do not check the “Master key Perfect Eorward Secrecy” button, and 
any values for when to rekey are acceptable. To ensure everything is set up the same 
as on the Cisco, click the “Methods” button, under “Protect identities with these 
security methods”. Now you will see the following new window. Use the sideways 
scroll bar to see if a security method exists with the same settings as on the router. 
Those values are IKE negotiation (Cisco calls it ISAKMP, which is actually its older 
name), 3DES encryption, SHAl Integrity (the hashing algorithm), and “Medium (2)” 
for the Piffle-Heilman size (which is Group 2, which is the 1024 bit Diffie-Heilman 
option, not the 768 bit one). If such a method does not exist, either modify a 
currently existing method by highlighting one and hitting the “Edit” button, or click 
the “Add” button to create a new one. In either case, you probably should click on 
the correct one (which will highlight it), and click the “Move up” button until it is the 
first option on the list. The others can either be deleted or just left there. 
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Click “OK”, and then click it again on the next window. You should now be back at 
the window where you selected the “General” tab. Now select the “Rules” tab and 
let’s continue. Click the “Add...” button, which will use a second wizard. When the 
introduction screen for the wizard shows up, click “Next”, which will make the 
following tunnel endpoint window appear. 



Since we selected transport mode when configuring the Cisco router, we do not need 
this tunnel. Continue on without specifying a tunnel. The next screen is about which 
network connections to use. 


Security Rule Wizard 


Network Type 

The security rule must be applied to a network type. 


Select the network type: 

N network connection^ 
Local area network (LAN) 
Remote access 


^x) 



< Back I Next > | Cancel | 


The network type “Remote access” is useful if you are using phone lines to connect 
remotely, but in this case, choose either LAN connection, or even better “All network 
connections” can be used. Click “Next”. Now is the time to enter the passphrase. 
Recall that we previously selected “my4pa$$phra$eHere” as our choice when we 
configured the Cisco router. 
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We enter that in the appropriate box, and click “Next”. The IP Filter List window 
will appear. Initially, it is probably empty. From there, click “Add” and the 
following IP Filter List definition window will appear. 



Now we need to add a filter. Name this filter (Cisco Only Filter, or something like 
that), but before you “Add”, unselect the “Use Add Wizard” option. This third wizard 
is not helpful. If you use the wizard, you get several screens in which you will type 
in the information you can supply to the one screen you see if you do not use the 
wizard. So, unselect the “Use Add Wizard”, click “Add” and you should see the 
following screen. 
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You want it to have the Source address as “My IP Address” and the Destination 
address as “A specific IP Address” in which you fill in the IP address of the Cisco 
router, 14.2.1.250. Use a subnet address of 255.255.255.255 which permits secure 
connections only to the one router and leaves all other communications unaffected. 
You do need to leave the mi rrored option on so filters are defined for traffic going in 
both directions. Click OK, returning you to the filter list window, which you should 
“Close.” Then select that filter (call it “Cisco Router Filter”) from the list of filters 
and click “Nexf’. 

The next window that appears is the Filter Action window. There are three default 
filters defined, “Permif’, “Request Security” and “Require Security”. Before 
selecting the “Require Security” option, you will want to examine it in a bit more 
detail to be sure that it contains the options you need. Double click on “Require 
Security” to see what options are set. It should look something like this. 
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Click on the security method preference order options and edit them to ensure that at 
least one of them contains the cryptographic settings for protecting the actual data 
that was configured in the Cisco. In fact, if you want to delete all but the one offer 
that is used, that would not be bad. For our example, we are using ESP with both 
3DES and SHA, and are not using the AH protocol. The lifetime (until keys are 
renegotiated) is not important, so any settings for that are acceptable. We want to 
select “Negotiate security” here. 

Choose “Accept unsecured communication, but always respond using IPSec”. We do 
not want to select the final two options, “Allow unsecured communications with non 
IPSec aware computer” and “Session key Perfect Forward Secrecy”. The reason we 
don't want to allow unsecured communications is that this IPSec configuration only 
applies to communication with the router, communication to other places is not 
affected and so not IPSec protected. For just this connection, we want to use 
security, so we require it. Perfect Forward Secrecy is a way to do a second key 
exchange, which is mostly used when the initial key exchange is shared. This is not 
the case here. When all these settings are correct, click “OK”. Highlight the 
“Require Security” button, and click “Next”. The only remaining thing to do is to 
click "Finish." The next time you connect to the Cisco router, IPSec will be activated 
automatically, and the traffic will be IPSec protected. 

After following all these steps, you have created an IP Security Policy, and that new 
policy will appear in the management console window. Make sure that the policy is 
actually in effect, typically you must explicitly assign a policy after creating it. Look 
at the third column, “Assigned”, of the policy listing in the management console 
window. If the column contains the word “No”, then right-click on it, and select 
“assign” from the popup menu. The value in the third column should change to 
“Yes” and the policy will be imposed. 
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A quick check to ensure that it is working is to ping the router from the Windows 
2000 host. The first attempt should fail and report "Negotiating IP Security". Ping a 
second time, and the router and the Windows 2000 host should have completed their 
key exchange and the ping should succeed. A network sniffer can be used to verify 
that communcations between the router and host are encrypted. On the router, use 
the command show crypto ipsec security-association to confirm that 
IPSec is being used. 
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5.3. Using a Cisco Router as a Firewall 

This section describes how to use a Cisco router as a modest firewall, if it is running 
a version of lOS that has firewall capabilities. To reach even a moderate level of 
effectiveness as a firewall, the router configuration must include good access lists; 
Section 4.3 describes access lists in detail. (Note: in mid-2000, Cisco renamed the 
lOS Firewall to “Cisco Secure Integrated Software.” Much of the documentation 
still uses the old name, and that is what we will use below. Current product catalogs 
and web pages use the new name.) 

5.3.1. Basic Concepts 

A network firewall is a network device that connects a protected internal network to 
some other untrusted, possibly hostile network. As long as all traffic between the 
tmsted and the untmsted network pass through the firewall, it can effectively enforce 
a number of network security capabilities. Stateful inspection firewalls do this by 
inspecting each packet for compliance with the specified security policy. 

Because routers connect networks together, many router vendors, include Cisco, 
provide a mdimentary firewall capability in their routers. The Cisco lOS Firewall 
feature set Content-Based Access Control (CBAC) facility allows a router to act as a 
mdimentary stateful inspection firewall. Configured together with good access lists, 
CBAC can provide modest firewall protection for a network without extra hardware. 

Another important feature for firewalls is hiding network addresses and stmcture. 
Cisco lOS provides full support for Network Address Translation (NAT). Using 
NAT, a router can hide the stmcture of the tmsted network, by transparently 
translating all IP addresses and coalescing distinct IP addresses into a single one. 
This guide does not describe NAT; consult the Cisco lOS documentation for 
information about lOS NAT features. 

5.3.2. Configuring Cisco lOS Content Based Access Control 

The Cisco lOS Firewall feature set is designed to prevent unauthorized, external 
individuals from gaining access to your internal network, and to block attacks on 
your network, while at the same time allowing authorized users on the tmsted 
network (the ‘inside’) access to services on the untmsted network (the ‘outside’). 
Potential applications for using a Cisco router as a firewall include: a quick-and-dirty 
Internet firewall, a firewall between two different communities of interest, and a 
firewall between a main network and a compartmented enclave. 

The figure below shows the basic stmcture for a CBAC-based firewall setup. The 
security policy for this setup is to permit users to take advantage of certain network 
services on the untmsted network, but to offer no such services in the other direction. 
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Figure 5-1: A Simple Router Firewall 

CBAC examines not only network layer and transport layer information, but also 
examines the application-layer protocol information (such as FTP information) to 
learn about the state of TCP and UDP connections. CBAC maintains connection state 
information for individual connections. The heart of CBAC is the ability to inspect 
outgoing IP traffic in real-time, maintain state information, and use the state 
information to make access decisions. The access decisions are enacted when CBAC 
dynamically adds mles to interface access lists to pass permitted traffic. The figure 
below illustrates this. Because CBAC works by modifying access lists, there must be 
at least one access list in place on the path from the untmsted network to the trusted 
network, either an inbound list on the outside interface, or an outbound list on the 
inside interface. 


1. Host initiates a web connection to 
web server 7.1.6.20 (port 80) on the 
untrusted network. 

2. CBAC inspects the initial TCP 
packet of the connection, and adds a 
rule to the inbound access list, 
permitting data from 7.1.6.20 port 80. 

3. Response comes back from the web 
server, passes access list. 


untrusted network 


outside interface 


Q- 


2 . 


inspect 


CBAC 


adjust 


access 

list 


Outbound R; it. Inbound 
request response 


inside interface 


3. 


□ 


trusted network 
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Figure 5-2: CBAC Overview 


Note that CBAC handles only TCP and UDP protocols. It also includes some special 
case handling for multi-port application protocols, like H.323 and FTP. Other IP 
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protocols and services, such as ICMP, OSPF, or IPSec, must be separately permitted 
by the interface access lists if you need them. 

Steps in Setting Up a Cisco Router Firewall 

To set up a simple firewall using CBAC, follow these steps: 

1. Check that the router supports CBAC, if it does not, then install an lOS 
version that does (see Section 4.5.5). 

Example: lOS 12.0(9) with Firewall Feature Set 

2. Determine the list of services that users or hosts on the trusted network 
need from the untmsted network. Call this list the desired services list. 
Example: FTP, Web (HTTP), SMTP, POPS, RealAudio (RTSP) 

3. Set up an outbound access list on the outside interface, prohibiting all 
traffic that should not leave the trusted network but allowing traffic on 
the desired services list (see Section 4.3). 

4. Set up an inbound access list on the outside interface, permitting traffic 
that the router must process, but prohibiting other TCP and UDP traffic 
including the desired services list. This is the access list that CBAC will 
be modifying on the fly. 

5. Create a CBAC inspection mleset supporting the desired services list. 

6. Set the CBAC global timeouts. These timeout values determine the 
duration of window of accessibility opened back through the firewall in 
response to a request from the tmsted network; values that are too long 
can leave the tmsted network vulnerable. 

7. Apply the CBAC inspection mleset to an interface, usually the outside 
interface. 

8. Test the configuration from a host on the tmsted network by mnning 
services, and test it from the untmsted network by mnning a network 
scanner (see Section 6). 

Step 1. Testing for CBAC Support on the Router 

Examine the router lOS installation to ensure it has the firewall feature set. There is 
no simple, direct way to check whether a router has CBAC capability. The easiest 
way to check is to execute a CBAC-related command, if the command fails, then 
CBAC is not supported. The two examples below show a router without CBAC, 
Central, and a router with CBAC, South. 

Central# show ip inspect all 
% Invalid input detected at marker. 


186 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED 


Advanced Security Services 


Central# 

versus 

South# show ip inspect all 

Session audit trail is disabled 
Session alert is enabled 


South# 

Step 2. Determine the Application Services to Support 

Decide which application-layer protocols to permit using CBAC. Best practice on a 
router is deny all protocols except those identified as needed. CBAC in lOS 12.0 
supports about a dozen application service types; the most commonly used ones are 
listed below. 


Service 

Definition 

Remarks 

Basic TCP 

Protocols 

Generic connected TCP 
protocols, such as HTTP, 
POP3, Telnet, SSL, etc. 

CBAC will support any of these; 
select ones to support by permitting 
them through the access list set up 
in Step 3. 

Other UDP 

Generic UDP services, such 
as DNS, NTP, TFTP, IKE, 
SNMP, etc. 

CBAC will support any of these; 
select ones to support by permitting 
them through the access list set up 
in Step 3. 

FTP 

Control connection on TCP 
port 21, data on TCP port 
>1024. 

CBAC has special support for FTP, 
and watches the FTP authentication 
exchange. It also prevents use of 
non-standard ports for FTP data. 

Mail (SMTP) 

Connect TCP protocol on 
port 25. 

CBAC permits only standard SMTP 
commands. 

H.323 

(NetMeeting) 

H.323 video conference 
protocol over UDP. 

Because NetMeeting uses additional 
non-standard ports, generic UDP 
must also be configured to use it. 

RealAudio 

(RTSP) 

Real-Time Streaming 

Protocol over UDP or TCP. 

CBAC automatically tracks the 
RealAudio port assignments. 


For web traffic (HTTP), CBAC has some ability to block Java applets. Because the 
Java blocking capability is very weak, it is not typically employed. 


For example, a reasonable list of desbed services for many installations is: DNS, 
NTP, HTTP, FTP, and Telnet, plus SMTP and POPS to the mail server only. 


Version l.Og 


UNCLASSIFIED 


187 

























Router Security Configuration Guide 


UNCLASSIFIED 


Step 3. Set up an Outbound Access List 

Before CBAC can do its work, there must be an access list applied to traffic from the 
trusted net to the untrusted net. This access list must permit the protocols on the 
desired services list. Also, this access list must be an extended IP access list. The 
source address for each rule in the access list should be a network address or address 
range valid for the trusted network; the destination address can be the catch-aU any. 
For more information about access lists, see Section 4.3. 

The example below shows an access list for our desired services list. In this example, 
the access list is applied to the outside interface, in the outbound direction; in general, 
this is a safe choice. 

South(config)# ! Create the access list 

South(config) # no access-list 110 

South(config) # ip access-list extended 110 

South(config-ext-nacl) # permit icmp 14.2.10.0 0.0.0.255 any 
South(config-ext-nacl) # permit udp 14.2.10.0 0.0.0.255 any eq ntp 

South(config-ext-nacl) # permit udp 14.2.10.0 0.0.0.255 any eq 

domain 

South(config-ext-nacl) # permit tcp 14.2.10.0 0.0.0.255 any eq www 

South(config-ext-nacl) # permit tcp 14.2.10.0 0.0.0.255 any eq ftp 

South(config-ext-nacl) # permit tcp 14.2.10.0 0.0.0.255 any eq 

telnet 

South(config-ext-nacl) # permit tcp 14.2.10.0 0.0.0.255 host 
14.2.9.3 eq smtp 

South(config-ext-nacl) # permit tcp 14.2.10.0 0.0.0.255 host 
14.2.9.3 eq pop3 

South(config-ext-nacl) # deny ip any any 
South(config-ext-nacl) # exit 

South (config)# ! Apply the access list to the outside interface 

South(config) # interface eth 0/0 

South(config-if) # ip access-group 110 out 

South(config-if) # exit 
South(config)# 


Step 4. Set up an Inbound Access List 

CBAC works by modifying inbound access lists; it can work with an access list 
applied to the interface on the tmsted or untrusted networks, or even both. An 
inbound access list intended for use with a simple CBAC firewall scheme should 
block all TCP and UDP services, even those on the desired servic es list. 

The example access list below blocks TCP and UDP traffic effectively, permits a 
modest set of useful ICMP messages, and permits the RIP routing protocol (see 
Section 4.3). 

South(config) # ! create inbound access list for CBAC to work on 

South(config) # no access-list 111 

South(config) # ip access-list extended 111 

South(config-ext-nacl) # permit icmp any any echo-reply 
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South(config-ext-nacl) # permit icmp any any unreachable 
South(config-ext-nacl) # permit icmp any any ttl-exceeded 

South(config-ext-nacl) # permit udp any any eq rip 
South(config-ext-nacl) # deny ip any any log 
South(config-ext-nacl) # exit 

South(config) # ! apply the access list to the outside interface 

South(config) # interface eth 0/0 

South(config-if) # ip access-group 111 in 

South(config-if) # exit 
South(config)# 


Step 5. Create a CBAC Ruleset 

To create a CBAC ruleset, use the command ip inspect name. The syntax is 
shown below. 

ip inspect name ruleset-name protocol [alert on/off] 
[audit-trail on/off] [timeout override-timeout] 

The alert option controls whether use of that protocol causes a console alert 
message to be generated; similarly, the audit-trail option controls whether use 
of that protocol causes a log message to be generated. Enable the alert and audit-trail 
features to get additional log messages, beyond those generate by interface access 
lists. (In older versions of CBAC, audit trails could only be turned on globally, using 
the command ip inspect audit-trail.) 

The example ruleset below supports the example desired service list. The name of 
the ruleset is “fwl.” Its first rule supports DNS and NTP, and the second mle 
supports web, Telnet, and POP3 email services. 

South(config) # ip inspect name fwl udp audit-trail on 

South(config) # ip inspect name fwl tcp audit-trail on 

South(config) # ip inspect name fwl ftp audit-trail on 

South (config) # ip inspect name fwl smtp audit-trail on 

South(config)# 


Step 6. Adjust the CBAC Global Parameters 

When CBAC detects a connection attempt by a client on the tmsted network, it adds 
a rule to the inbound access list to permit the expected response. This mle gets 
removed when one of the following conditions are satisfied: 

■ The response does not arrive within the allotted timeout time. 

■ The connection is idle for longer than an allotted idle time. 

■ The connection closes down (TCP only). 
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The default timeout and idle times in Cisco lOS 12.0 are longer than necessary. 
There are also global CBAC parameters related to half-open TCP session, but these 
can be left at their default values. The table below describes the parameters to 
change. 


Timeout Name Description Default Suggested 


Synwait-time 

Length of time CBAC waits for a 
new TCP session to reach 
established state. 

30 seconds 

15 seconds 

Finwait-time 

Length of time that CBAC 
continues to manage a TCP 
session after it has been closed 
down by a FIN exchange. 

5 seconds 

1 second 

TCP idle-time 

Length of time that CBAC 
continues to manage a TCP 
session with no activity. 

1 hour 

30 minutes 
(1800 sec.) 

UDP idle-time 

Length of time that CBAC 
continues to manage a UDP 
‘session’ with no activity. 

30 seconds 

15 seconds 


Of course, these values might need to be increased for a very slow connection (e.g. a 
modem) or on a highly congested network. 

The example below shows how to set the global timeout parameters. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# ip inspect tcp synwait-time 15 
South(config)# ip inspect tcp finwait-time 1 
South(config)# ip inspect tcp idle-time 1800 
South(config)# ip inspect udp idle-time 15 
South(config)# exit 
South# 


Step 7. Apply the CBAC Ruleset to the Interface 

CBAC is not in force until a mleset has been applied to at least one interface. Use 
the interface configuration command ip inspect name to apply a ruleset. The 
example below applies the ruleset from step 5 to the outside (untrusted network) 
interface. 

South# config t 

Enter configuration commands, one per line. End with CNTL/Z. 

South(config)# interface ethO/0 

South(config-if)# ip inspect fwl out 

South(config-if)# end 

South# show ip inspect interface 

South# 
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After this step, CBAC should be running on the router. 

Step 8. Test the CBAC Configuration 

Perform some simple tests from a host on the trusted network, to see that CBAC is 
working. The test shown here has two parts: first, starting a telnet session from a 
host on the trusted network to a host on the untrusted network, and second, 
confirming that CBAC is managing the session. For more detailed testing 
information, see Section 6. 

The example below shows a Telnet session from a host on the trusted network 
(14.2.10.6) to a host on the untrusted network (14.2.9.250). 

$ telnet 14.2.9.250 

Trying 14.2.9.250... 

Connected to 14.2.9.250. 

Escape character is . 

Welcome to the CENTRAL router. No unauthorized users, 
please! 

Username: nziring 
Password: 

Central> 

While the Telnet session is active, check the CBAC session status on the router using 
the command show ip inspect sessions. It should show the telnet session, as 
illustrated in the example below. If the command gives no output, then CBAC is not 
working. 

South# show ip inspect 

Established Sessions 
Session 6187B230 (14 

SIS_OPEN 
South# 

If the CBAC configuration seems to be working, save the router configuration to 
NVRAM at this point with the command copy running startup. 

5.3.3. Configuration Sample 

The configuration command listing below shows the configuration commands for a 
firewall router with a simple CBAC configuration. The desired service list for this 
firewall is: DNS, NTP, HTTP, FTP, Telnet, SMTP (to a single host), and POPS (to a 
single host). This sample is formatted as it would appear in a configuration text file 
stored on a host for download to the router South. 

no access-list 110 

ip access-list extended 110 

permit icmp 14.2.10.0 0.0.0.255 any 


sessions 

.2.10.189:3175)=>(14.2.9.250:23) tcp 
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permit udp 14.2.10 
permit udp 14.2.10 
permit tcp 14.2.10 
permit tcp 14.2.10 
permit tcp 14.2.10 
permit tcp 14.2.10 
permit tcp 14.2.10 
deny ip any any 
exit 


0 

0 

0 

0 

0 

0 

0 


0.0.0.255 

0.0.0.255 

0.0.0.255 

0.0.0.255 

0.0.0.255 

0.0.0.255 

0.0.0.255 


any eq ntp 

any eq domain 

any eq www 

any eq ftp 

any eq telnet 

host 14.2.9.3 eq smtp 

host 14.2.9.3 eq pop3 


no access-list 111 

ip access-list extended 111 

deny ip 14.2.10.0 0.0.0.255 any log 

permit udp any any eq rip 

permit icmp any any echo-reply 

permit icmp any any unreachable 

permit icmp any any ttl-exceeded 

deny ip any any log 

exit 


ip 

inspect 

name 

fwl 

udp 

audit-trail 

on 

ip 

inspect 

name 

fwl 

tcp 

audit-trail 

on 

ip 

inspect 

name 

fwl 

ftp 

audit-trail 

on 

ip 

inspect 

name 

fwl 

smtp 

audit-trail 

on 

ip 

inspect 

tcp 

synwait-time 15 


ip 

inspect 

tcp 

finwait-time 1 


ip 

inspect 

tcp 

idle- 

-time 

1800 


ip 

inspect 

udp 

idle- 

-time 

15 



interface eth 0/0 
ip access-group 110 out 
ip access-group 111 in 
ip inspect fwl out 
end 


192 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED 


Advanced Security Services 


5.4. References 

[1] Chapman, D.B., Cooper, S., andZwicky, E.D. Building Internet Firewalls, 2nd 
Edition, O’Reilly Associates, 2000. 

A seminal reference for understanding firewalls and the principles for 
building them. 

[2] Cisco lOS 12.0 Network Security , Cisco Press, Indianapolis, IN, 1999. 

Authoritative source for in-depth descriptions of security-related lOS 
facilities, including IPSec, CBAC, and related configuration commands. 

[3] Doraswamy, N. and Harkins, D. IPSec: The New Security Standard for the 
Internet, Intranets, and Virtual Private Networks, Prentice-Hall, 1999. 

Contains a good overview of IPSec, plus and technical detail about IKE and 
VPN design. 

[4] Kent, S. and Atkinson, R., “Security Architecture for the Internet Protocol,” 

RPC 2401, 1998. 

The master document for IPSec, includes extensive remarks about VPN 
architecture. 

[5] Tiller, J. A Technical Guide to IPSec Virtual Private Networks, Auerbach 
Publishcations, 2001. 

This highly technical book provides detailed explanations and pragmatic 
advice about IPSec. 

[6] “Cisco Secure Integrated Software Configuration Cookbook”, Cisco 
Configuration Cookbook, Cisco Systems, 2001. 

available at http : / /www .cisco . com/warp/public/7 93/ios_fw/ 

This page offers detailed configuration examples for CBAC. 

[7] “Cisco Secure VPN Client Solutions Guide”, Cisco Internetworking Solutions 
Guides, Cisco Systems, 1999. 

available at 

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csvpnc/c 
svpnsg/ 

[8] “How to Configure IPSec Tunneling in Windows 2000”, Q252735, Microsoft 
Knowledge Base, Microsoft Corporation, 2000. 

available under http : //support .microsoft. com/support/ 

Contains some good information about setting up IPSec in Windows 2000. 


Version l.Og 


UNCLASSIFIED 


193 





Router Security Configuration Guide 


UNCLASSIFIED 


[9] “Overview of Secure IP Communication with IPSec in Windows 2000”, 
Q231585, Microsoft Knowledge Base, Microsoft Corporation, 2000. 
available under http: //support .microsoft. com/support/ 

A good overview of IPSec features in Windows 2000. 

[10] “Security Technical Tips - IPSec”, Cisco Technical Assistance Center, Cisco 
Systems, 2000. 

available at http: //www.cisco.com/warp/public/707/#ipsec 

This page offers detailed descriptions of about a dozen sample IPSec 
configurations, as well as links to other IPSec information on Cisco’s 
web site. 

[11] Virtual Private Networks”, Cisco Technical Assistance Center Top Issues, Cisco 
Systems, 2000. 

available at: http : / / www .cisco . com/warp/public/471/top_issues/ 
vpn/vpn_index.shtml 

A collection of resources and links for Cisco IPSec and VPN information. 


194 


UNCLASSIFIED 


Version l.Og 





UNCLASSIFIED 


Testing and Security Validation 


6. Testing and Security Validation 

6.1. Principles for Router Security Testing 

The perimeter router is the first line of defense when protecting against malicious 
attack. Routers provide many services that can have severe security implications if 
improperly configured. Some of these services are enabled by default whereas other 
services are frequently enabled by users. Security testing provides a means of 
verifying that security functions and system operations are configured in a secure 
manner. 

Ideally, testing should be performed at initial deployment of a router, and whenever 
major changes have been made to the any part of the configuration of a router. 

6.2. Testing Tools 

There are a variety of tools available for testing purposes. Scanners such as Fyodor’s 
nmap program are used to scan for open TCP and UDP ports on a router interface. 
Packet sniffer programs are used to monitor traffic passing through the network and 
steal unencrypted passwords and SNMP community strings; this information can 
then be used to formulate specific attacks against the router. Attack scripts are 
readily available on the Internet for numerous well-known exploits; several denial of 
service (DOS) attacks and the newer distributed denial of service (DDoS) attacks 
have been highly successful against some versions of lOS. 

Additional tools are listed in the Tools Reference, Section 9.3. 
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6.3. Testing and Security Analysis Techniques 

6.3.1. Functional Teste 

Functional testing provides assurance that the implemented configuration is the 
intended one. Access lists should be tested thoroughly once assigned to an interface 
both to be certain that necessary traffic is permitted and unwanted traffic is denied. 
Additionally, some services depend on other services in order to function. For 
example, DNS must be available for any operation referencing a host by name to 
succeed (e.g. Telnet). Testing all allowed services will identify these dependencies. 

To view the current operational configuration, use the EXEC mode command show 
running-config. A serious known problem with Cisco lOS is that some default 
settings are not displayed as part of the router configuration listing. The above 
command would not, for exampb, show the ‘udp-small-servers’ or the ‘tcp-small- 
servers’ in the configuration. The default settings for these services depend upon the 
lOS version; for lOS v.11.2, the default is enabled, but for lOS v.11.3, the default is 
disabled. To verily the entire configuration, mn a port scan against the router. The 
nmap scanning program is a good tool for this purpose. The examples below show 
nmap mnning under Linux. (Note: if IP unreachable messages have been disabled, as 
advised in Section 4.3, temporarily re-enable them before performing your UDP port 
scan by using the interface configuration command ip unreachable.) 

TCP Scan: 

The following command will perform a TCP scan against router North (IP address 
14.2.1.250): 

# nmap -sT 14.2.1.250 -p 1-65535 

Starting nmap v. 2.12 by Fyodor (fyodor@dhp.com) 

Interesting ports on (14.2.1.250): 

Port State Protocol Service 

If VTY (Telnet) access is not allowed, there shouldn’t be any ports open. Otherwise, 
cross-check the ports that nmap reports open against the services that the router is 
supposed to be mnning. 

UDP Scan: 

The following command will perform a UDP scan against router North (14.2.1.250): 

# nmap -sU -p 1-65535 14.2.1.250 

Warning: -sU is now UDP scan; for TCP FIN use -sF 

Starting nmap v. 2.12 by Fyodor (fyodor@dhp.com) 

Interesting ports on (14.2.1.250): 

Port State Protocol Service 
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6.3.2. Attack Tests 

Attack testing can provide some assessment of the router’s robustness, i.e., how the 
router will perform under the stress of an attack. 

Warning: Running attack scripts against an operational router may 

DEGRADE ROUTER PEREORMANCE, OR EVEN CAUSE THE ROUTER TO CRASH! 

If the filters are improperly configured, or not applied to the interface, some of 
these attacks will have the same effect as a “real’ attack from a malicious source. 

Do Not perform attack testing against an operational router without first 
considering the possible consequences and having a recovery plan. If possible, 
perform testing in a lab or testbed environment rather than the operational 
environment. If you do perform testing on the operational network, make sure 
that all attack testing is coordinated with those responsible for the network and 
choose a test time when the network usage is likely to be low. 

Connecting to an outside network exposes the internal network and the perimeter 
router to many potential risks. One of the most important security concerns is access 
to the router itself. Physical security of the router should provide protection from 
close-in access. On the network, remote access must be limited using authenticated 
logins or, if possible, remote logins should be disabled. To test the remote 
availability, telnet to the router. The router should either refuse the request or prompt 
for a password. For a more detailed discussion of Cisco router access security and 
remote administration, consult Section 4.1, and the Cisco whitepaper “Improving 
Security on Cisco Routers” [1]. 

Once access to the router has been secured, the network is still at risk of attack. 

Some of the most common attacks on the internet are denial of service (DoS) attacks. 
DoS attacks are typically based on high-bandwidth packet floods or other repetitive 
packet streams. The easy availability and effectiveness of DoS scripts on the internet 
make these attacks a favorite among hackers, particularly those without the skill to 
create their own tools. For a general overview of DoS, visit the CERT site: 
http :/ /www.cert.org/tech_tips/denial_of_service.html. For more 
information on the effects of DoS attacks, including recent developments and links to 
specific DoS advisories, visit: http : / /www. cert. org/summaries/. 

One very popular DoS attack is the ‘smurf’ attack. This attack has at least two 
victims - a target system and one or more reflector systems. The attacker sends a 
continuous stream of ICMP echo requests (‘pings’) to the broadcast address of a 
reflector subnet. The source address in these packets is falsified to be the address of 
the ultimate target. Each packet generates a response from all hosts on the reflector 
subnet, flooding the target and wasting bandwidth for both victims. The reflector 
networks receiving these echo requests can prevent the attack by using the no ip 
directed-broadcast command (see Section 4.2). Eor a detailed discussion of the 
smurf attack, read Craig Huegen’s paper [9] 
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New developments in denial of service tools have recently become available on the 
internet. These distributed denial of service tools (DDoS) pose a major threat to 
networked systems and have the potential to severely impact normal business 
activities. Unlike a “typical” smurf attack, which uses a limited number of reflector 
systems, these tools employee many compromised systems to simultaneously attack a 
single target. The real attacker is able to amplify the DoS flooding while being 
removed from the attacking machines; tracking the attacker is extremely difficult. 
There are currently four such tools in circulation: Tribal FloodNetwork (TFN), 

TrinOO, Tribal FloodNetwork 2000 (TFN2K) and Stacheldraht. Cisco routers can 
help prevent the system behind the router from being an unwitting participant in a 
DDoS attack by using the ip verify unicast reverse-path interface 
command (Section 4.4.5). This feature checks each packet arriving at the router; if 
the source IP address does not have a route in the CEF tables pointing back to the 
same interface on which the packet arrived, the packet is dropped. Asynchronous 
routing will not work with this feature, and it is only available in lOS vl2.0; similar 
protection can be achieved by filtering for IP spoofing, described below. More 
information about DDoS attacks is available from references [3], [4], [5], and [8]. 

Another common DoS attack, the SYN flood, takes advantage of the TCP three-way 
handshake procedure to deny service to the victim. In a normal TCP connection 
request, the requesting client sends a SYN packet to the server. The server responds 
with a SYN/ACK packet, adds an entry in the connection queue and starts a timer. 
The requester then compbtes the handshake with an ACK packet; the queue entry is 
removed, the timer is reset and the connection is established. In a SYN flood, an 
attacker sends a TCP connection request (SYN) packet with an unreachable, spoofed 
source address to an open port on the target. The victim responds with a SYN/ACK 
to the unreachable host and waits for the ACK; the ACK doesn’t arrive and the TCP 
handshake never completes. The attacker continues to send these forged SYN 
packets at a rapid rate until the victim’s connection queue is fdled with half-open 
requests. The effect of this attack is to deny TCP services such as e-mail, file transfer 
or web traffic to legitimate users. Blocking access to the service under attack is 
usually not feasible and would accomplish precisely what the attacker set out to do. 
However, victims of a SYN flood do have some options. The host could increase the 
size of the connection queue, requiring the attacker to send more phony packets to 
flood the service. The host could also decrease the wait time for completion of the 
three-way handshake, thus emptying the queue of half-open connections more 
quickly. For more options, Cisco provides a paper titled “Defining Strategies to 
Protect Against TCP SYN Denial of Service Attacks” [4]. 

An integral part of DoS and DDoS attacks is IP spoofing, i.e., changing the source IP 
address to hide the tme source of the packet. For Cisco routers mnning lOS v. 11.2 or 
11.3, filters can be used to prevent IP spoofing in a manner similar to the ip verify 
unicast reverse-path feature discussed above. Access lists should check that no 
packets arriving from the outside network contain a source address of either the 
internal network or the well-known, non-routable, reserved addresses (defined in 
RFC1918). Also, arriving packets should not have source addresses of all O’s or all 
I’s or the loopback address (127.0.0.0). Additionally, packets arriving at the router 
from the internal network should not have a source address that is not one of the 
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legitimate internal addresses. (Note that the internal network may be using one of the 
RFC1918 reserved addresses with NAT performed at the router; in this case, the 
access list on the internal interface will recognize such an address as legitimate. The 
goal here is to catch packets with a source address of an external network or a 
reserved address that is not being used by the internal network.) This check will 
prevent the internal network from being used as a launch point for a source IP 
spoofing attack. To verify the anti-spoofing configuration, send a series of packets 
with modified source addresses to the external interface. The packets should test the 
ability of the router to detect both internal addresses and reserved addresses that 
should not arrive at an external port. The router should drop these packets at the 
perimeter and log the events. To verify outbound anti-spoofing, send packets to the 
router’s internal interface with source addresses that are not legitimate internal 
addresses; the router should again drop the packets and log the events. RFC 2267 
discusses network ingress filtering and defeating DoS attacks which employee IP 
source address spoofing. For an in-depth discussion of TCP flooding and IP spoofing, 
consult [7]. 

There is a Cisco syslog vulnerability that may cause the lOS software to crash if an 
invalid user datagram protocol (UDP) packet is received on the syslog port (port 
514). This vulnerability affects unpatched versions of lOS 11.3AA, 11.3DB and 
early (non-GD) releases of 12.0. Some vulnerable lOS devices will “hang” and must 
be manually restarted by reset or power cycle; it might require an administrator to 
physically visit the attacked device to restore service. At least one commonly 
available internet scanning tool can generate these UDP packets. By sending such 
packets continuously, an attacker might be able to completely disable a Cisco lOS 
device until the affected device is reconfigured to drop the problem traffic. This 
problem can be prevented by applying the appropriate input access list to all 
interfaces that might receive these packets. This input access list must block traffic 
destined for UDP port 514 at any of the Cisco lOS device’s own IP addresses, as well 
as at any broadcast or multicast addresses on which the device may be listening. If a 
specific interface is not expected to forward legitimate syslog traffic, an alternative 
fix would be to deny all syslog traffic arriving on that interface. The following 
example shows an access list to block the port 514 UDP traffic. 

! Deny all multicasts and all unspecified broadcasts to port 514 
access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514 
! Deny old-style unspecified net broadcasts 
access-list 101 deny udp any host 0.0.0.0 eq 514 

! Deny network specific broadcasts, in this example, the 14.2.0.0 
! network behind router North (both old-style and new broadcasts) 
access-list 101 deny udp any 14.2.0.255 0.0.255.0 eq 514 
access-list 101 deny udp any 14.2.0.0 0.0.255.0 eq 514 

! Deny packets addressed to router interface 
access-list 101 deny udp any host 14.2.0.20 eq 514 
! Apply to input interface of router North 
interface ethO 
ip access-group 101 in 
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This vulnerability can be tested by sending a UDP packet to the router’s port 514. 
However, if the router is running a vulnerable version of the lOS software and the 
access list is not properly configured or not applied, the router will crash or hang! 

As mentioned above, running DoS attack scripts against the router can have very 
serious and undesirable consequences. If, after careful consideration, planning and 
coordination, the decision is made to go forward with this testing, the attack scripts 
are readily available from many sources on the internet. At the time of this writing, 
Packetstorm Security has several DoS exploits, available under 
http://packetstorm.security.com/exploits/DoS/ and 
http://packetstorm.securify.com/spoof/. 

Other useful sites for exploit information and code are listed at the end of this 
section. 

6.3.3. Mechanisms for Automated Testing 

There are a number of products available to automate the testing process. CyberCop 
Scanner from Network Associates and Internet Scanner from ISS are two popular 
commercial products. The Security Administrator’s Integrated Network Tool 
(SAINT) and the Security Administrator Tool for Analyzing Networks (SATAN) are 
publicly available tools. 

Warning: Running automated attack tools entails significant risk ! 

It is easy to accidentally auto-scan more systems than you intended, or to touch 
systems for which you have no legal authority. Exercise caution when using 
tools like CyperCop, SAINT, or SATAN; always double-check the addresses to 
be scanned, and monitor the tools closely while they are operating. 

CyberCop Scanner performs comprehensive evaluations of intranets, web servers, 
firewalls and screening routers by scanning them and performing extensive tests to 
identify known vulnerabilities. CyberCop generates reports from scan results that 
include information about detected vulnerabilities: a description of the vulnerability, 
security concerns, level of risk and suggestions for fixing/mitigating the 
vulnerability. CyberCop offers monthly updates consisting of new modules and 
security hotfixes for new and evolving vulnerabilities. For more information, visit: 
http://www.nai.com/asp_set/solutions/activesecurity/acts_produ 
cts.asp 

Internet Scanner is also a network vulnerability analysis and risk assessment product. 
Internet Scanner probes the network’s communication services, operating systems, 
key applications and routers for those vulnerabilities frequently used by malicious 
users to investigate and attack networks. Internet Scanner includes nearly 600 total 
tests, and updates containing the latest tests and security checks are available for 
download daily. Internet Scanner analyzes the scan data and provides reports 
containing vulnerabilities identified along with recommended corrective actions. The 
latest version of Internet Scanner (6.01) now contains tests to find hosts infected by 
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DDoS agents. For more information, visit: 

http://WWW.iss.net/securing_e-business/security_products/ 

SAINT gathers information about remote hosts and networks by examining network 
services such as finger, NFS, NIS, ftp, tftp, rsh commands and other services. The 
initial data collection can then be used to investigate any potential security problems. 
SAINT can also be configured to examine trust and dependency relationships in the 
target network; this feature exposes the real security implications inherent in network 
tmst and services. For more information, including a FAQ, a tutorial and the latest 
version of SAINT, visit: http : / /www. wwdsi . com/saint /index . html 

SATAN was designed to help system administrators responsible for the security 
posture of their systems; it is a tool for investigating the vulnerabilities of remote 
systems. SATAN systematically proceeds through a target network probing for 
common networking-related weaknesses and security problems. The vulnerabilities 
discovered are then reported to the user without actually exploiting them. For each 
problem found, SATAN offers a tutorial that explains the problem and the potential 
impact. SATAN also provides corrective actions including configuration changes, 
installing vendor bugfixes, or possibly disabling services. For more information or to 
download a copy of SATAN, visit the COAST file archive site: 

ftp://coast.cs.purdue.edu/pub/tools/unix/satan 


6.3.4. Detecting Attacks 

As mentioned in section 6.3.2 above, denial of service attacks are very common on 
the internet. lOS access lists can be used to characterize the different packet types 
and to tentatively identify DoS attacks. Assume the following access list is applied to 
interface 14.2.0.20 of router North: 

access-list 102 permit icmp any any echo log-input 

access-list 102 permit icmp any any echo-reply log-input 

access-list 102 permit tcp any any established 

access-list 102 permit tcp any any log-input 

access-list 102 permit ip any any 

interface serial 0 
ip access-group 102 in 

This access list does not filter out any traffic but does separate the traffic by types. 

An analysis of the packets arriving on the serial interface can identify the specific 
attack being used, a necessary first step in countering DoS attacks. To see the 
number of matches for each line in the access list, use the command show access- 
list 102. For more information about access lists, consult Section 4.3. 

The signature of a smurf attack where router North is the ultimate target would show 
most of the packets as ICMP echo replies. If the incoming traffic consists mostly of 
ICMP echo requests, the attack is probably a smurf attack where North is a reflector. 
In a typical smurf attack, the source addresses in the echo reply packets are limited to 
a few networks; these are the addresses of the reflector sites. 
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The third and fourth lines of access list 102 characterize TCP traffic. The keyword 
established in the third line matches any TCP traffic with the ACK bit set, that is, any 
TCP traffic that is not a connection request. The fourth line therefore matches only 
packets that are connection requests, the TCP SYN packets. In normal operations, 
TCP SYN packets account for a third or less of the total TCP traffic. In a SYN flood, 
these SYN packets typically outnumber other TCP packets many times over. Also, 
SYN floods usually contain packets with invalid source addresses; logging such 
traffic (as recommended in Section 4.3) will determine if such source addresses are 
present. 

There is a paper on the Cisco web site titled “Characterizing and Tracing Packet 
Floods Using Cisco Routers”. This paper gives an overview of denial of service 
attacks and a detailed discussion of using access lists to categorize packets. The 
paper also describes how to trace DoS attacks and the complications inherent in 
packet tracing [2]. 

6.3.5. Attack Reaction Options 

It is difficult for the ultimate target of denial of service attacks to stop or even blunt 
an active attack. If it can be determined that the originators of the attack are limited 
to a few addresses, it may be possible to apply specific filters at the external interface 
of the border router. If filtering is not possible, or not sufficient to stop the attack, the 
only response may be to contact the reflector sites to reconfigure their networks to 
shut down the attack. In a distributed attack, the ultimate target cannot filter out the 
attacking addresses. In this case, the upstream provider to the victim may be able to 
filter out all ICMP echo replies to the target network; this filter should only be in 
place temporarily and only as a stopgap measure. 

It is almost impossible to protect a network from denial of service attacks. The best 
advice is to configure the router to check for IP spoofing, both inbound and 
outbound, and to only allow services that are needed (see Sections 4.2 and 4.3). An 
on-going problem is that new attacks can appear so fast on the internet that 
countermeasures are not immediately available. Still, the only defense is to be 
vigilant about security and to keep up with that latest security news by regularly 
checking a site such as CERT and implementing the latest patches from the vendors. 
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7. Future Issues in Router Security 

This section describes a few areas of network technology that will probably have an 
effect on router and network security in the near future. The list is not 
comprehensive, the topics described below are merely a select few of the many 
technologies that network security administrators will have to incorporate into their 
security plans and policies in the next few years. 

7.1. Routing and Switching 

As network bandwidth demands continue to increase, IP routing will increasingly be 
replaced by layer 2 switching in high-performance applications. The security 
concerns for switched networks and switches correspond directly to those for routed 
networks and routers. 

■ Protecting physical access to the switch itself 

■ Controlling virtual access to the switch, including user authentication and 
authorization 

■ Updating the operating system when necessary to fix known 
vulnerabilities 

■ Preventing unauthorized modification of the switch configuration 

■ Disabling unneeded services and features 

Switching imposes new risks, while removing the ability to impose some security 
restrictions. For example, routers supply critical protection at network boundaries by 
filtering traffic (see Section 4.3). Switches typically have limited or negligible 
filtering capabilities. Therefore, in a network environment that is predominantly 
based on switching, each individual host and device must be configured securely 
rather than relying on protection at their LAN boundaries. 

One feature of switched environments that might be usable to improve security is 
virtual LAN switching. Many Ethernet switches have the ability to maintain one or 
more separate virtual LANs over the same physical cables and switches. The 
diagram below shows how virtual LANs can be set up to emulate two physical LANs 
spread across two switches. Note that some switches can act as routers between their 
separate VLANs, while others require a real router. 
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More investigation is needed to determine the security roles and policies for 
configuring VLANs, but it is clear that VLAN security will grow in importance in the 
next few years. 
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7.2. ATM and IP Routing 

Asynchronous transfer mode (ATM) switched networks are popular for backbones 
and long-haul high-speed network links. ATM is a very big topic, most of which is 
out of the scope of this guide. Sometimes, the boundary between switched ATM and 
routed IP will be a switch or router with one or more ATM interfaces and one or 
more traditional LAN or WAN interfaces (e.g. Ethernet, Frame Relay). 

Cisco routers support three mechanisms for sending IP traffic over ATM switched 
networks. 

1. Classical IP - 

This is the oldest technique, and offers very simple configuration at the 
cost of flexibility and performance. 

2. LANE- 

LAN Emulation (LANE) is a fairly general, standardized technique for 
extending an IP LAN over an ATM switched network. It offers a great 
deal of flexibility, but requires a great deal of configuration to deploy. 

3. MPOA- 

Multi-Protocol Over ATM (MPOA) is a highly flexible set of 
mechanisms for transporting IP and other protocols over ATM switched 
networks. Used with LANE, MPOA allows routers and other network 
devices to take advantages of advanced ATM facilities (like ATM 
quality-of-service). 

The security implications of choosing one of these modes over another are not yet 
entirely clear. 


Version l.Og 


UNCLASSIFIED 


207 





Router Security Configuration Guide 


UNCLASSIFIED 


7.3. IPSec and Dynamic Virtual Private Networks 

Section 5.2 explains some of the basic features of IPSec. However, IPSec and 
Virtual Private Network (VPN) configutation are complex topics. As deployment of 
VPNs becomes more common, the simple configurations described in Section 5.2 
probably will not scale well enough satisfy users’ needs. To achieve scalability, 
VPNs will need to be dynamic, employing public keys and public key certificates to 
set up IPSec-protected links on the fly 

Security configuration issues are likely to be important in deployment of large 
dynamic VPNs are listed below. 

■ PKI enrollment and obtaining certificates - 

To participate in a dynamic VPN based on Public Key Infrastmcture 
(PKI), a router or any other device must possess a copy of the correct root 
and authority certificates, and it must have its own certified public key and 
private key. Installing certificates and setting up authorities on Cisco 
routers is complex but well-documented. There are also tmst issues in any 
large VPN deployment: are all members of the VPN tmsted equally? In 
general, IPSec is most useful for integrity and confidentiality assurance, 
but not for authorization or access control. 

■ Designating traffic to be encrypted - 

Cisco routers, and most other VPN systems, support the ability to protect 
certain traffic based on its protocol and port numbers. Currently, there are 
no uniform guidelines for selecting traffic to protect. 

■ Certificate revocation - 

In any large-scale PKI, removing certified principals from the tmsted 
community is very important. PKI standards define various data formats 
and protocols for defining revocations and for checking certification status 
(e.g. X.509 CRL format, OCSP). It may be necessary to configure 
revocation checking on routers participating in dynamic VPNs. 

■ Cryptographic issues - 

Selection of uniform key sizes and cryptographic algorithms will be a 
contentious issue in VPN deployment. Cisco routers currently support 
only a small complement of algorithms, depending on the installed lOS 
version and feature set. 

For complete information on the IPSec and dynamic VPN capabilities of Cisco lOS 
12.0, consult Cisco lOS 12.0 Network Security [2]. 
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7.4. Tunneling Protocols and Virtual Network Applications 

As VPNs become more popular and widespread, expect a corresponding increase in 
mobile users expecting to join home base networks, VPNs, and protected networks 
from remote sites. Standard protocols exist for tunneling layer 2 protocols, such as 
Ethernet or PPP, over IP networks. Use of such tunneling protocols allows remote 
users to join a LAN, and actually use their home base LAN address, from a remote 
part of the network. There are several approaches to doing this, each of which has 
different security issues. 

7.4.1. Virtual Private Dialup Networking 

Cisco routers support tunnelling dial-up protocols, like PPP, over IP from a remote 
router or network access server to a central router. This kind of tunneling 
architecture is called Virtual Private Dial-up Networking (VPDN), and it is illustrated 
in the figure below. 



14 . 2 . 9.185 


Figure 7-2: Overview of Virtual Private Dial-up Networking 

In general, the security for a VPDN service depends on use of IPSec between the two 
ends of the tunnel: the remote network access server and the central router. This is an 
area that needs further study, but it seems possible that small deployments could use 
static IPSec tunnels as described in Section 5.2. 
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7.5. IP Quality of Service and RSVP 

The Resource reSerVation Protocol (RSVP) is the Internet standard protocol for 
setting up Quality-of-Service (QoS) parameters for traffic in routed IP networks. 
Many releases of Cisco lOS 12.0 and later support RSVP and QoS guarantees. As 
bandwidth-hungry network clients, such as IP video-conferencing systems, begin to 
gain wide acceptance, users will begin to demand quality-of-service assurances. 

Quality-of-service support offers the potential for substantial denial-of-service 
attacks. On routers that support RSVP but that do not need to provide any QoS 
guarantees, all RSVP messages should be denied on external interface using IP 
access-lists. For more information about access lists, consult Section 4.3. 

In general, RSVP configuration will probably be a contentious issue, and configuring 
it securely will be challenging. While the RSVP protocol itself includes provisions 
for authentication and authorization, key management and deployment issues for 
RSVP security have not been resolved. Also, Cisco lOS 12.1 now supports 
centralized application of RSVP policies, but the security issues associated with this 
facility have not yet been explored. Extensive guidance already exists for integrating 
IP QoS (RSVP) with ATM QoS, but the security issues involved in that integration 
have not been fully explored. 
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7.6. Secure DNS 

The Domain Name System (DNS) used on the Internet and other major networks 
provides the mapping between names (like central.mydomain.com) to IP addresses 
(like 14.2.9.250). The basic DNS protocol offers no authentication or integrity 
assurance. 

The DNS Security Extensions standard defines comprehensive integrity and 
authentication facilities for DNS. In a network with secure DNS, the mapping 
between names and addresses is fully authenticated and integrity assured. These 
security services are supported by the latest versions of the primary Internet DNS 
server implementation, Bind. Given the negligible deployment that secure DNS has 
enjoyed in the first year or so that it has been widely available, it seems unlikely that 
it will become ubiquitous. 

Cisco routers do not yet support acting as a secure DNS client (in other words, the 
domain name resolver in Cisco lOS cannot recognize or check DNS security 
extensions). In a network with secure DNS, it would be possible to gain some of the 
security benefits by configuring the router name server (configuration command ip 
name-server) to be a local secure DNS server. The local secure DNS server would 
have to be configured to perform secure DNS requests on behalf of its non-security 
capable clients like the router. It could then perform the security checks on remote 
DNS requests, and pass along only validated results. 
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8. Appendices 

The sections below offer ancillary material and supplementalguidance for network 
and security administrators. 

8.1. Top Ways to Quickly Secure a Cisco Router 

This appendix describes the most important and effective ways to tighten the security 
of a Cisco router, along with some important general principles for maintaining good 
router security. The descriptions here are terse, for more details consult the 
corresponding parts of Section 4. References to appropriate parts of Section 4 appear 
at the end of each recommendation. 

General Recommendations 

Comment and organize the offline edition of router configuration file! This sounds 
fluffy despite being a big security win. Also, keep the offline copy of all router 
configurations in sync with the actual configuration running on the routers. This is 
invaluable for diagnosing suspected attacks and recovering from them. [Section 4.1] 

Implement access list filters by permitting only those protocols and services that the 
network users really need, and explicitly denying everything else. Trying to deny just 
the ‘bad things’ is a losing proposition. [Section 4.3] 

Run the latest available General Deployment (GD) lOS version. [Sections 4.5.5, 8.3] 


Specific Recommendations 

1. Shut down unneeded services - things that aren't running can't break, and 
save memory and processor slots too. Start by running the show proc 
command on the router, then turn off clearly unneeded facilities and 
services. Some services that should almost always be turned off are 
listed below. 

■ CDP - Cisco Discovery Protocol is used almost exclusively by 
Cisco RMON; CDP sends packets from your router once a minute 
or so identifying your router. Use the no cdp run command to 
kill the process and disable CDP globally. To leave CDP mnning 
but disable it for certain network connections, apply the command 
no cdp enable to the appropriate interfaces. [Section 4.2] 

■ Small services - miscellaneous UDP (echo, discard, chargen) and 
TCP (echo, discard, chargen, daytime) based services. One of 
these is the UDP echo which is used in the ‘fraggle’ attack. Use 
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the commands no service udp-small-servers and no 
service tcp-small-servers to turn these off. [Section 4.2] 

■ Finger - the finger daemon. Use the command no service 
finger (lOS 11.2 and earlier) or no ip finger (lOS 11.3 and 
later). [Section 4.2] 

■ NTP - the Network Time Protocol. If NTP is not being employed 
for time synchronization, turn if off with no ntp server. NTP 
can also be disabled for only a specific interface with the no 
ntp enable command. [Sections 4.2, 4.5] 

■ BOOTP - the IP bootp server. Turn off this little -used server with 
the command no ip bootp server. [Section 4.2] 

2. Don't be a Smurf buddy! While the Smurf attack doesn't usually attack 
the router itself, a Smurf attack can let an attacker use your network to 
launch denial of service raids on other sites; the attacks will appear to 
come from you. To prevent this, use the command no ip directed- 
broadcast on all interfaces. This may be the default on some recent 
versions of lOS, but include it in your configuration explicitly anyway. 
[Section 4.2] 

Central(config)# interface eth 0/0 

Central(config-if )# no ip directed-broadcast 

3. Shut down unused interfaces using the shutdown command. Check 
them with the show interfaces command. If the router has an auxiliary 
console port (aux port) and it is not in use, shut it down as shown below. 
[Section 4.1] 

Central(config)# interface eth 0/3 

Central (config-if)# shutdown 

Central(config-if) # exit 

Central(config)# line aux 0 

Central(config-line) # no exec 

Central(config-line) # transport input none 

Central (config-line) # exit 


4. Always start an access-list definition with the command no access- 
list nnn to make sure it starts out clean. [Section 4.3] 

East(config) # no access-list 51 

East(config) # access-list 51 permit host 14.2.9.6 
East(config) # access-list 51 deny any log 

5. Log access list port messages properly. For reasons of efficiency, Cisco 

105 doesn't look at an entire packet header unless it has to. If packets are 
rejected by an access list filter for other reasons, the log message will 
often list the packet as using “port 0”. To prevent this from happening, 
instead of the usual logging access list command (such as access-list 

106 deny ip any any log), use the special port range arguments 
shown below. 
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no access-list 106 

access-list 106 deny udp any range 0 65535 any range 0 65535 log 

access-list 106 deny tcp any range 0 65535 any range 0 65535 log 

access-list 106 deny ip any any log 

The last line is necessary to ensure that rejected packets of protocols 
other than TCP and UDP are properly logged. [Section 4.3] 

6. Password and access protect the Telnet VTYs. By default, virtual 
terminals (telnet) are unprotected. To set a password, use password 
command. To control access, use a access list and the access-class 
command. Finally, if only one method of attaching to the VTY, such as 
Telnet, is to be permitted, use the transport input command to 
enable only that method. [Section 4.1] 

South(config)# line vty 0 4 

South(config-line)# login 

South(config-line)# password Soda-4-JlMMY 

South(config-line)# access-class 2 in 

South(config-line)# transport input telnet 

South(config-line)# exit 

South(config)# no access-list 92 

South(config)# access-list 92 permit 14.2.10.0 0.0.0.255 

Controlling authentication for login to the router is an extremely 
important topic, consult Sections 4.1 and 4.6 for guidance. 

7. Unless the network is one of those very rare setups that needs to allow 
source routed packets, the source routing facility should be disabled with 
the command no ip source-route. [Section 4.2] 

Central(config) # no ip source-route 

8. Turn off SNMP trap authentication to prevent a remote SNMP system 
shutdown request. In lOS 11.2 and later use the global configuration 
command no snmp-server enable traps. If SNMP is not being 
used on the router, turn it off with the command no snmp-server. 
[Sections 4.2, 4.5.3] 

South(config) # no snmp-server enable traps 

South (config) # no snmp-server 

9. Make sure that the router enable password is encrypted using the strong 
MD5-based algorithm by us ing the enable secret command rather 
than the enable password command. [Section 4.1] 

South(config) # enable secret 2Many-Routes-4-U 

South(config)# 

10. Allow only internal addresses to enter the router from the internal 
interfaces, enforce this using access-lists. Block illegal addresses at the 
outgoing interfaces. Besides preventing an attacker from using the router 
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to attack other sites, it helps identify mis-configured internal hosts and 
networks. This approach may not be feasible for very complicated 
networks. [Section 4.3] 

East(config) # no access-list 101 

East(config) # access-list 101 permit ip 14.2.6.0 0.0.0.255 any 

East(config) # access-list 101 deny udp any range 1 65535 any log 

East(config) # access-list 101 deny tcp any range 1 65535 any log 

East(config) # access-list 101 deny ip any any log 

East(config) # interface eth 1 

East(config-if )# ip access-group 101 in 

East(config-if) # exit 

East(config) # interface eth 0 

East(config-if) # ip access-group 101 out 

East(config-if) # end 


11. Turn on the router’s logging capability, and use it to log errors and 
blocked packets to an internal (trusted) syslog host. Make sure that the 
router blocks syslog traffic from untrusted networks. [Section 4.5] 


Central(config)# 
Central(config)# 
Central(config)# 
Central(config)# 


logging buffered 
logging trap info 
logging facility locall 
logging 14.2.9.6 


12. Block packets coming from the outside (untmsted network) that are 
obviously fake or are commonly used for attacks. This protection should 
be part of the overall design for traffic filtering at the router interface 
attached to the external, untmsted network. [Section 4.3] 


■ Block packets that claim to have a source address of any internal 
(tmsted) networks. This impedes some TCP sequence number 
guessing attacks and related attacks. Incorporate this protection 
into the access lists applied to interfaces connected to any 
untmsted networks. 


■ Block incoming loopback packets (address 127.0.0.1). These 
packets cannot be real. 

■ If the network does not need IP multicast, then block it. 

■ Block broadcast packets. (Note that this may block DHCP and 
BOOTP services, but these services should not be used on 
external interfaces.) 

■ A number of remote attacks use ICMP redirects, block them. (A 
superior but more difficult approach is to permit only necessary 
ICMP packet types.) 


The example below shows how to enforce these mles on router North 

North(config)# 

North(config)# 

North(config)# 


no access-list 107 

! block internal addresses coming from outside 
access-list 107 deny ip 14.2.0.0 0.0.255.255 any log 


North(config)# 
North(config)# 


access-list 107 deny ip 14.1.0.0 
! block bogus loopback addresses 


0.0.255.255 any log 
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North(config) # access-list 107 deny ip 127.0.0.1 0.0.0.255 any log 
North(config) # ! block multicast 

North(config) # access-list 107 deny ip 224.0.0.0 0.0.255.255 any 
North(config) # ! block broadcast 

North(config) # access-list 107 deny ip host 0.0.0.0 any log 
North(config) # ! block ICMP redirects 

North(config) # access-list 107 deny icmp any any redirect log 


North(config) # interface eth 0/0 

North(config-if) # ip access-group 107 in 


13. Block incoming packets that claim to have the same destination and 
source address (i.e. a ‘Land’ attack on the router itself). Incorporate this 
protection into the access list used to restrict incoming traffic into each 
interface, using a rule like the one shown below (part of the 
configuration file for router East). [Section 4.3] 

no access-list 102 

access-list 102 deny ip host 14.2.6.250 

host 14.2.6.250 log 
access-list 102 permit ip any any 

interface Eth 0/0 

ip address 14.2.6.250 255.255.255.0 
ip access-group 102 in 

14. Prevent the router from unexpectedly forwarding packets with no clear 
route by using the global configuratbn command no ip classless. 
[Section 4.2] 

15. Proxy ARP is used to set up routes on the fly for internal hosts or subnets 
and may reveal internal addresses. Disable it by applying the command 
no proxy-arp to each external interface. If proxy ARP is not needed, 
disable it on all interfaces. [Section 4.2] 

Central(config) # interface eth 0/0 
Central(config-if) # no proxy-arp 

16. Except on the rarely-seen Cisco 1000 series routers, the HTTP server is 
off by default. To be safe, however, include the command no ip 
http server in all router configurations. [Section 4.2] 

17. To disable the use of subnetting with a zero subnet address (which is 
confusing and illegal) include the command no ip subnet-zero in 
all router configurations. 

18. So that the complete date and time are stamped onto entries in the routers 
buffered log, use the global configuration command service 
timestamps as shown in the example below. [Section 4.5] 
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East(config) # service timestamps log date \ 
msec local show-timezone 

East(config)# 

19. Unless the router absolutely needs to autoload its startup configuration 
from a TFTP host, disable network autoloading with the command no 
service config. [Section 4.2] 

20. Turn on password encryption, so that regular passwords are stored and 
displayed in scrambled form. This provides some security against casual 
‘over-the-shoulder’ attacks. [Section 4.1] 

East(config) # service password-encryption 

21. If the router has a separate bootflash image, make sure that the lOS 
bootflash image version is reasonably cbse to the current lOS version. 
To check the current boot version use the command show boot. [Note: 
only a few Cisco router models (e.g. 4700) have a separate bootflash 
image; if the router responds to show boot with “Invalid input” then 
this recommendation does not apply.] 

For more information about testing router security, and defeating common attacks, 
see Section 6. 
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8.2. Application to Ethernet Switches and Related Non-Router 
Network Hardware 

This appendix identifies specific principles and recommendations from the main 
body of this guide that apply to Ethernet switches, managed hubs, access servers, and 
other network hardware components that are not IP routers. Prior to the 1990s, 
routers were the only LAN components with sufficient flexibility to need security 
configuration. Since the mid-1990s, hubs, switches, access servers, and other LAN 
components have been gaining substantial capabilities; many of them are as flexible 
and configurable as a router. Such devices almost always support remote 
administration and management, and are therefore subject to compromise over the 
network. Because they are vital to network operations and because they can be used 
as a staging area for additional attacks, it is important to configure them securely. 

The discussion below focuses mainly on media-level network components: switches, 
managed hubs, and bridges. These devices are characterized by participation in the 
network itself but forwarding and switching traffic based on a media layer address 
(e.g. an Ethernet MAC address). Because they cannot perform network layer or 
transport layer traffic filtering, switches and hubs cannot generally enforce security 
policies on network traffic. The focus for security for these devices is protecting 
their own configuration, and preventing their use by unauthorized individuals and 
attacker. 

Another kind of common network device that needs protection is the access server. 
An access server is a device that services a set of phone lines, and provides dial-up IP 
access for remote users. These kinds of devices usually have very extensive security 
and remote administration support, and configuring them securely requires a great 
deal of care. Configuring access servers is outside the scope of this guide. 

8.2.1. Security Principles and Goals 

The general security goals for a switch or smart hub are similar to those for a router, 
but simpler because such a network component does not act as a boundary device 
between different networks. The security goals for a switch or hub are listed below. 

■ preventing unauthorized examination of device state and configuration 

■ preventing unauthorized changes to the device state and configuration 

■ preventing use of the device for attacking the local network 

■ preventing unauthorized remote management/monitoring of the device 

To achieve these goals, the device must be configured to strictly limit all forms of 
access: physical, local connections, and remote network connections. If possible, it is 
best to create a security checklist for LAN switches. Lollow the general form of the 
security checklist given at the end of Section 3. 
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8.2.2. Application to Cisco lOS - based LAN Equipment 

Cisco makes several kinds of network switches, but they can be divided into two 
broad groups: those that use Cisco lOS or a derivative (e.g. 2900 series) and those 
that do not use lOS (e.g. Catalyst 5000 series). While the command syntax and 
command interface structure differ between Cisco lOS-based and other equipment, 
the same general principles apply to all of them. The syntax shown in Section 4 will 
work for lOS-based switches, but will not generally work on other devices. 


Much of the security guidance given in Section 4 that can be applied to lOS-based 
Cisco switches, and even some smart Ethernet hubs. Before attempting to apply the 
detailed instmctions from section 4, check whether the particular switch is mnning 
lOS or some other operating system. If you do not have the switch documentation 
handy, login to the switch and use the show version command to display the 
operating system name; the operating system name and version are underlined in the 
examples below. 


lOS-based Catalyst 2900 

sw20c# show version 

Cisco Internetwork Operating System Software 
IQS (tm) C2900XL Software (C2900XL-H-M), 
Version 11.2(8)SA, RELEASE SOFTWARE (fcl) 


Non-IOS Catalyst 5500 

CatSk# show version 

WS-C5505 Software, Version McpSW: 4.5(1) 
NmpSW: 4.5(1) 


sw20c uptime is 6 days, 3 hours, 9 minutes 


System Bootstrap Version 5.1(2) 


sw20c# 


Uptime is 45 days, 3 hours, 51 minutes 
Cat5k# 


The table below describes how to apply the guidance in each part of Section 4 to 
lOS-based LAN switches. 


Section Topic Application to Switches 


4.1 

Access security 

All of this section applies to switches: setting up users and 
passwords, remote access restrictions, and configuration 
loading and maintenance. 

4.2 

Network service 
security 

Most of this section applies to switches; any network 
service that is related to routing usually is not supported on 
a switch, and thus does not need to be configured. 

Especially important for 2900 switches is restricting access 
to the HTTP server. In addition, all ports should be 
configured to block traffic to unknown addresses using the 
port block interface configuration command. 

4.3 

Access lists 

lOS-based switches support IP access lists, but do not use 
them for as many different purposes as a router does. 
Basically, on a switch, access lists are used for limiting 
access to services on the switch itself, but not for filtering 
traffic passing through the switch. 
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Section Topic Application to Switches 


4.4 

Routing 

protocols 

This section is not generally applicable to switches. 

[Note: some Catalyst 5000 and higher series switches are 
equipped with a ‘Route Switch Module’. This module is 
essentially a 4700-series lOS router attached to the switch. 

It should be configured using Section 4 like any other 
router.] 

4.5 

Audit and 
Management 

Almost all of this section applies to lOS-based switches; 
some switch lOS versions do not support NTP, and must 
have their time set manually. All switches support RMON 
and SMTP; they should be disabled if not in use, or access 
to them should be restricted. 

4.6 

Access control 

with AAA 

All of this section is applicable to lOS-based switches, if 
they support AAA (lOS 11.2 and later). 


Note that Cisco switch-resident routing hardware (e.g. Catalyst 5000 series Route 
Switch Modules) can and should be configured using the guidance in Section 4, after 
careful consideration of its role in the network security policy. 

Most of the security testing guidance given in Section 6 also applies to LAN 
switches. 
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8.3. Overview of Cisco lOS Versions and Releases 

Cisco provides a very large number of software releases for their routers and other 
products. This appendix provides an overview of the major release levels, and the 
release naming scheme. It is intended to help with upgrade strategies and version 
selection. In general, operational routers should kept up to date with the newest 
stable release that provides all the needed features. Often it will not be practical to 
install all the updates that Cisco makes available, especially during the flurry of bug 
fix releases that tends to follow a major change. Devise a consistent upgrade strategy 
that matches the needs of your network, and then follow it; use this appendix and the 
materials listed in the references, to understand what Cisco provides. 

8.3.1. Release Levels and Names 

Cisco follows strict naming schemes for lOS releases. Unfortunately, the format has 
changed several times since lOS was first introduced in the mid-1990s. The current 
format for a Cisco lOS release name is shown below. 


VV.N.M RR Examples: 

^-Release identifier 12.0.3 Release =12.0 

Revision = 3 

Maintenance revision number 

11.3.5T Release =11.3 

- Minor release number _ . . , 

Revision = 5 

_lOS Major release Identifier = T 

number: 10, 11, 12 


Figure 8-1 - Cisco lOS Release Naming 

In general, release number and release identifiers tell what features could be 
available, and the revision number tells how many times the release has undergone 
fixes to correct problems. Cisco releases may be broadly divided into kinds: regular 
shipping releases (general or limited) and early releases. A regular release will 
almost always have a simple number with no release identifier, such as 12.0.8. An 
early release will usually include an identifier, and may also include a number in 
parentheses. For example, the release “12.1.3T” is lOS version 12.1, revision 3, 
identifier T. The ‘T’ identifier designates an early release of new technology 
features. For operational purposes, it is usually best to avoid early release software, 
unless it has some required, critical feature. There is a complex naming scheme for 
early releases that is beyond the scope of this guide; consult [1] for complete details. 
Some of the suffixes that you might see on special-purpose releases include “XA”, 
“HA”, “F’. You might also see maintenance revision numbers in parentheses, 
usually for ED releases; for example, 11.2(9)XA. 
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Every Cisco lOS release has a release type. The table below describes the types. 


Type 

Description 

Remarks 

ED 

Early Deployment - a pre-shipping release that 
supports new features, protocols, or hardware. 

This could be considered 
the ‘beta’ release for an 

lOS version. 

LD 

Limited Deployment - this is the status of a 
release when it is first shipped to customers 
(ECS). Releases at this level are sometimes 
pre-installed on routers sold by Cisco. 

LD releases are usually 
stable, but have not 
undergone the extensive 
customer shakedown and 
bug fixes of a GD release. 

GD 

General Deployment - a stable shipping release 
suitable for general use. Most Cisco routers 
sold come with a GD release pre-installed. 

The most stable type of a 
release, a GD has usually 
been subject to several 
rounds of bug fixes since 
first shipping. 

DF 

Deferred Release - a release that was built and 
named, but later retracted. 

DE releases are not 
available to customers. 


The revision numbers for a given release run sequentially, even as the release status 
moves from ED to GD. As an example, look at lOS 12.0: for the 3640 router, 12.0.1 
was ED, 12.0.4 was ED, and 12.0.8 was GD. 

Releases, Features, and the Cisco lOS Upgrade Planner 

Every Cisco lOS release is built with a variety of feature sets. The feature sets have 
names that are roughly evocative of what the features are; two common names are 
“Ip Plus” and ‘Enterprise/Appn”. All feature sets support basic IP routing and 
filtering, but some also support firewall or IPSec functions (see Section 5) or 
mainframe protocols, or telephony. lOS versions with more features will require 
more memory, so it is generally a good idea to use the simplest feature set that meets 
the network’s needs. Some commercial organizations customarily purchase routers 
with the maximum memory capacity pre-installed, to give the greatest latitude for 
future expansion. 

The Cisco web site provides a “Software Center” where authorized customers can 
download software products, including Cisco lOS releases. The part of the software 
center that contains the lOS releases is called the “Cisco lOS Upgrade Planner.” 
Registered Cisco customers with software maintenance contracts may download lOS 
releases via the Upgrade Planner; it supports choosing versions in a very flexible 
way. It presents the different available releases in a friendly tabular arrangement, and 
allows you to select items of interest (hardware mode, feature set, release number) in 
any order. 

When you use the lOS Upgrade Planner to select a particular lOS software release, it 
supplies the hardware and memory requirements for that release before permitting 
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you to download it. Be very careful to check these requirements against the router on 
which you hope to run the software, ensure that amounts of installed memory meet or 
exceed the requirements before attempting to load the lOS release. 

8.3.2. Major Releases and their Features 

There are at least five major releases of Cisco lOS software currently in use in 
operational environments: 11.1, 11.2, 11.3, 12.0, and 12.1. The lists below describe 
some of the major features introduced into lOS in each of these releases, with 
emphasis on security-relevant features. 

All earlier Cisco lOS releases, 11.0 and 10.x, are now unsupported by Cisco, 
although they are still available for download. 

lOS 11.1 

The 11.1 release was the last lOS release to use the old ‘classic’ or monolithic 
architecture. While exceedingly stable and robust, it did not offer extensive security 
features. lOS 11.1 was first deployed in 1996, and engineering development for it 
was dropped in 1999. Some of the important features 

■ RIPv2 (see Section 4.5) 

■ The lOS web server and web browser management interface [11.1(5) and 
later] 

■ RADIUS support (as part of AAA, see Section 4.7) 

■ RMON support (see Section 4.6) 

■ Lock-and-Key dynamic access lists 

lOS 11.1 is available as a GD release for all older Cisco routers, but is not available 
for some of the popular newer models (e.g. 7500, 1605, 3660). 

lOS 11.2 

The 11.2 release was the first lOS version to fully implement Cisco’s modular 
architecture for router software. A great many new features were added to lOS over 
the lifetime of 11.2, a few of them are listed below. 

■ Named access control lists (See Section 4.4) 

■ Network address translation (NAT) 

■ Support for RSVP and IP Quality-of-Service (see Section 7.5) 

■ Support for LANE (IP over ATM) 

■ Various OSPF and BGP4 enhancements 
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■ Initial support for TCP Intercept (11.2F only) 

■ Early (pre-IPSec) VPN support 

■ Early versions of the lOS firewall feature set and CBAC (see Section 5.3) 

lOS 11.2 is available as a GD release for many popular Cisco router models, but not 
all of them. 

lOS 11.3 

11.3 was used to introduce a large number of new features into lOS, but it was never 
officially shipped as a GD release. Some of the features introduced in 11.3 are listed 
below. 


■ Initial implementations of IPSec (11.3T) 

■ Cisco Encryption Technology (CET) VPNs 

■ Enhancements to AAA (See Section 4.7) 

■ Eull lOS firewall feature set and CBAC (11.3T) 

■ Reflexive access lists 

■ TCP Intercept (full availability) 

■ Initial support for VLAN routing 

■ Enhanced lOS filesystem and initial support for FTP 

■ HTTP authentication for the lOS web server 

lOS 11.3 is available for almost all Cisco router models, but only at the ED and ED 
release levels. 

lOS 12.0 

The 12.0 and 12.0T releases brought together a wide variety of features that had 
previously been available only in selected ED and ED releases of lOS 11. 12.0 was 
designed to be the basis for future router software releases, and to help eliminate the 
confusion of specialized releases that plagued 11.1 through 11.3. Some of the 
security-relevant features introduced or consolidated in 12.0 are listed below. 

■ Eull support for the Eirewall feature set and CBAC 

■ Initial version of lOS Intmsion Detection (IDS) 

■ Eull support for IPSec 

■ Commented IP access list entries 
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■ Full support for the Layer 2 Tunnelling Protocol (L2TP) 

■ SNMP version 3 (See Section 4.6) 

■ Time-based access lists 

■ General availability of ip unicast reverse-path verification [Section 4.4] 

lOS 12.0 is available in both LD and GD forms for all supported Cisco router 
platforms, and many other Cisco hardware products. 

lOS 12.1 

The 12.1 release is an incremental step forward from 12.0. While it is expected to 
reach GD status, as of late 2000 it was only available at the ED and LD release 
levels. Some of the security features to appear in 12.1 so far are listed below. 

■ Enhanced IPSec certificate management and AAA integration 

■ AAA accounting enhancements 

■ Unicast reverse path forwarding security enhancements 

■ Initial support for Secure Shell (SSH Version 1) client and server 

8.3.3. References 

[1] Coulibaly, M.M., Cisco lOS Releases: The Complete Reference, Cisco Press, 
2000 . 

This highly specialized book covers the Cisco lOS release system and release 
history in painstaking detail. 
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8.4. Glossary of Router Security-related Terms 

AAA 

Authentication, Authorization, and Accounting - 
The advanced user access control and auditing facility in 

Cisco lOS 11 and 12. (See also RADIUS and TACACS+) 

ACL 

Access Control List - See “Access List” 

Access List 

A set of rules that identify, permit, or restrict network 
traffic, usually based on addresses and other information 
from the packet headers. Cisco lOS depends heavily on 
access lists for traffic filtering, access to router services, 

IPSec configuration, and more. 

AH 

Authentication Header - a part of IPSec, the packet format 
and protocol for IP integrity assurance services, (see also 

IPSec, IKE, ESP) 

ARP 

Address Resolution Protocol - link-layer protocol used for 
mapping from IP addresses to MAC addresses in LAN 
environments. ARP is standardized in RFC 826. (See also 

MAC Address, LAN, Proxy-ARP) 

ATM 

Asynchronous Transfer Mode - virtual-circuit oriented link 
layer protocol, used for network backbones, LANs, and 
telecommunications facilities. (See also LANE) 

BGP 

Border Gateway Protocol - an advanced routing protocol 
mostly using on backbone routers. BGP is standardized in 

RFC 1267. 

CBAC 

Content-Based Access Control - packet inspection system 
used for application firewall functionality in Cisco routers. 

CDP 

Cisco Discovery Protocol - a proprietary link layer protocol 
that Cisco routers use to identify each other on a network. 

Not commonly used today. 

CEF 

Cisco Express Forwarding - a proprietary packet transfer 
technology used inside most Cisco router models. 

DHCP 

Dynamic Host Configuration Protocol - UDP-based 
protocol for assigning host network attributes, like IP 
addresses and gateways, on the fly. DHCP is standardized 
in RFC 2131. 
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DNS 

Domain Name System - hierarchical naming scheme used 
for host and network names on most IP networks, including 
the Internet. DNS is also the name for the protocol used to 
transmit and relay domain name information. DNS is 
standardized in RFCs 1034 and 1035. 

DoS 

Denial of Service - this abbreviation is often used for 
network attacks that prevent a network component from 
providing its operational functions, or that crash it. 

DDoS 

Distributed Denial of Service - This abbreviation is used for 
DoS attacks that use multiple (usually hundreds or more) 
coordinated network data sources to attack a single victim. 

EIGRP 

Extended Interior Gateway Routing Protocol - A Cisco 
proprietary routing protocol, not commonly used (see also 

OSPF). 

Enable mode 

A slang expression for a privileged EXEC session on a 

Cisco router, derived from the command used to request 
privileged EXEC mode: enable. 

ESP 

Encapulated Security Payload - a part of IPSec, the packet 
format and protocol for IP confidentiality services (see also 

IPSec, IKE, AH) 

FTP 

File Transfer Protocol - widely-used TCP-based file transfer 
and file management protocol. Typically, FTP control 
messages are passed on TCP port 21. FTP is standardized in 
RFC 959. 

ICMP 

Internet Control Message Protocol - a support protocol used 
along with IP for control and status message. ICMP is a 
network layer protocol that provides error messages and 
management capabilities in IP networks. ICMP is 
standardized in RFC 792. 

IETF 

Internet Engineering Task Force - the technical and 
consultative body that defines standards for the Internet. 

IETF standards are published by RFC number, the list of 
current standards is RFC 2400. 

IKE 

Internet Key Exchange - the standard security negotiation 
and key management protocol used with IPSec. IKE is 
standardized in RFC 2409. 

lOS 

Internet Operating System - Cisco’s name for the modular 
software system that runs on their routers and some other 
network devices. 
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IP 


IPSec 


ISAKMP 


Kerberos 


LAN 

LANE 

MAC Address 

MD5 

MIB 

MPOA 

Multicast 


NNTP 

NTP 


Internet Protocol - The network-layer protocol on which the 
Internet is built. There are two extant versions of IP: IPv4 
and IPv6. IPv4 is standardized in RFC 791. IPv6 is 
standarized in RFC 1883. 

[Note: all the discussion in this guide concerns IPv4.] 

Internet Protocol Security - a set of standards that define 
confidentiality and integrity protection for IP traffic. IPSec 
is standardized by a set of RFCs including RFC 2401. 

Internet Security Association Key Management Protocol - 
one of the precursors of IKE (see also IKE, IPSec). 

Kerberos was developed by the Massachusetts Institute of 
Technology as a network authentication system, and it 
provides strong authentication for client/server applications 
by using secret-key cryptography. Kerberos is standardized 
in RFC 1510 (see also RADIUS). 

Local Area Network - general term for a single -segment or 
switched network of limited physical and organizational 
extent. 

LAN Emulation - A standard mechanism for routing IP 
packets over ATM. 

Media Access Control address - the link layer address of a 
network interface, especially Ethernet interfaces. An 
Ethernet MAC address is 48 bits long. 

Message Digest algorithm 5 - a widely-used cryptographic 
checksum algorithm, standardized in RFC 1321. 

Management Information Base - the hierarchical data 
organization used by SNMP. (See also SNMP) 

Multi-Protocol Over ATM - A proposed standard 
mechanism for hosting network protocols (such as IP) over 
ATM. (See also LANE) 

An operational feature of IP, in which packets can be 
broadcast to partic ular recipients based on address. In IPv4, 
addresses from 224.0.0.0 to 225.255.255.255 are usually 
multicast group addresses. 

Network News Transfer Protocol - a TCP -based application 
protocol that usually runs on port 119. 

Network Time Protocol - the standard network time 
synchronization protocol, can use UDP or TCP, but usually 
uses UDP, port 123. NTP is standardized in RFC 1305. 
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OSPF 

Proxy 

Proxy-ARP 

RADIUS 

RFC 

RIP 

RMON 

Routing 

RSVP 

SMTP 

SNMP 

Syslog 


Open Shortest Path First - an IP routing protocol that uses a 
link-state distance metric. OSPF is standardized in RFC 
2328. (See also RIP) 

Any application that acts as an intermediary in the network 
exchanges between two applications or services. Proxy 
applications are often employed to moderate exchanges 
through a firewall. 

A facility offered by some routers where a router responds 
to ARP queries from a connected LAN on behalf of hosts on 
other LANs. Rarely used. 

The Remote Authentication Diafln User Service (RADIUS) 
is specified by the IETF RFC 2058. Using RADIUS, access 
servers can communicate with a central server to 
authenticate, authorize, and audit user activities. 

Request For Comments - a document describing an Internet 
standard, proposed standard, or information related to or 
supports a standard. (See IETF) 

Router Information Protocol - a simple inter-gateway 
routing protocol that uses hop count as its distance metric. 
RIP is standardized by RFCs 1088, 1388, and 1723. (See 
also OSPF) 

Remote MONitoring - facilities for remote performance and 
traffic monitoring of network devices, based on SNMP. 

Direction and management of paths through a multi-segment 
network. (See also RIP, OSPF) 

Resource reSerVation Protocol - fairly new standard 
protocol for requesting quality-of-service guarantees in IP 
networks. RSVP is standardized in RFC 2205. 

Simple Mail Transfer Protocol - a TCP-based protocol for 
sending and relaying e-mail messages. SMTP is 
standardized in RFC 821. 

Simple Network Management Protocol - datagram protocol 
used for monitoring and configuring network devices. 

SNMP uses UDP ports 161 and 162. SNMP is standardized 
in RFC 1157 and other RFCs. (See also RMON); 

A very simple UDP-based protocol used for logging by 
Unix systems and Cisco routers. Syslog usually employs 
UDP port 514. 
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TACACS+ Terminal Access Controller Access Control System Plus - a 

security protocol to provide centralized authentication, 
authorization, and accounting of users accessing a router or 
access server. TACACS+ is defined by Cisco. 

TCP Transmission Control Protocol - connection-oriented data 

protocol used with IP. TCP supports a large number of 
application layer network services, including Telnet, web, 
FTP, and e-mail. 

Telnet A simple TCP-based protocol for remote login, usually on 

port 23. Also used to refer to client applications that support 
the protocol. 

TFTP Trivial File Transfer Protocol - simple UDP-based fde 

transfer protocol, distinguished by its lack of any support for 
authentication. TFTP normally uses UDP port 69. TFTP is 
standardized in RFC 1350. 

UDP User Datagram Protocol - message-oriented data protocol 

used with IP. UDP is the basis for many core network 
services, including DNS, RIP, and NTP. UDP is 
standardized in RFC 768. 

VPDN Virtual Private Dialup Network - an application of VPN 

technology to secure remote-dialup connections, giving a 
remote user secure connectivity to their ‘home base’ 
network, (see also VPN) 

VPN Virtual Private Network - a closed network of 

communicating computers or LANs, using the public 
network as the transport. Usually the traffic between 
members of the VPN is protected by IPSec during transit 
over the public network. 

VTY Virtual TeletYpe - an interface on a host or router that 

provides the interactive services of a terminal interface. 
Cisco routers use VTY lines to host Telnet sessions (see 
Telnet). 


Cisco offers an large glossary of Internetwork technology terms and acronyms at 
their web site: http: //www.cisco. com/univercd/cc/td/doc/cisintwk/ita/. 
Explanations and documentation about a very wide variety of protocols may be found 

at http://www.protocols.com . 
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9. Additional Resources 


The references below can be useful in designing secure network configurations, and 
in understanding and maintaining router security. 


9.1. Bibliography 

The list below consists of books that are useful for router configuration and security, 
collected from the reference lists throughout this guide. 


Albritton, J. Cisco I OS Essentials, McGraw-Hill, 1999. 

An excellent introduction to basic usage and configuration of lOS routers. 

Ballew, S.M., Managing IP Networks with Cisco Routers, O’Reilly Associates, 1997. 

A practical introduction to the concepts and practices for using Cisco routers, 
with lots of pragmatic examples. 

Black, U. IP Routing Protocols, Prentice Hall, 2000. 

A very good survey of routing protocols and the technologies behind them, 
with some discussion of applications. 

Buckley, A. ed. Cisco lOS 12.0 Configuration Fundamentals, Cisco Press, 1999. 

This is the reference manual and guide for basic configuration tasks in lOS 
12.0. Sections particularly relevant to Router Access Security include: lOS 
User Interfaces and File Management. 

Chapman, D.B., Cooper, S., and Zwicky, E.D., Building Internet Firewalls, 2nd 
Edition, O’Reilly & Associates, 2000. 

A seminal overview of network boundary security concerns and techniques. 
This revised edition includes all the sound background of the original, with 
extensive updates for newer technologies. 

Chappell, Laura, Editor, Advanced Cisco Router Configuration, Cisco Press, 1999. 

Great reference book for a variety of Cisco configuration topics, including 
routing and routing protocols. 

Cisco lOS 12.0 Configuration Fundamentals, Cisco Press, 1999. 

The configuration fundamentals guide and reference in book form; handy to 
have, but the documentation CD is usually easier to use. 
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Cisco lOS Release 12.0 Security Configuration Guide, Cisco Press, 1999. 

This is the reference manual and guide for major security features in lOS 
12.0. Sections particularly relevant to Router Access Security include: 
Security Overview, Configuring Passwords and Privileges, and Traffic 
Filtering and Firewalls. 

Doraswamy, N. and Harkins, D. IPSec: The New Security Standard for the Internet, 
Intranets, and Virtual Private Networks, Prentice-Hall, 1999. 

Contains a good overview and substantial technical detail about IPSec and 
related topics. 

Held, G., and Hundley, K., Cisco Access List Field Guide, McGraw-Hill, 1999. 

This book offers detailed information and examples on access list syntax and 
usage. 

Held, G. and Hundley, K., Cisco Security Architectures, McGraw-Hill, 1999. 

This book includes excellent general advice about router and router-related 
network security, in addition to its Cisco-specific material. 

Moy, J.T. OSPF - Anatomy of an Internet Routing Protocol, Addison-Wesley, 1998. 

Detailed analysis of OSPF and MOSPF, with lots of practical advice, too. 
Includes a good section on troubleshooting. 

Parkhurst, W.R. Cisco Router OSPF - Design and Implementation Guide, 
McGraw-Hill, 1998. 

Comprehensive and practical guide to OSPF use. Includes discussion of 
design issues, security, implementation, and deployment. 

Rybaczyk, P., Cisco Router Troubleshooting Handbook, M&T Books, 2000 

A very practical book, oriented toward finding and correcting problems with 
router connectivity and routing protocols. 

Stevens, W.R., TCP/IP Illustrated, Vo/wme i, Addison-Wesley, 1994. 

The most comprehensive and readable guide to the TCP/IP protocol suite; 
great technical background for any network analyst. 

Thomas, T.M. OSPF Network Design Solutions, Cisco Press, 1998. 

This book starts with a good overview of IP routing and related technologies, 
then goes on to explain how to configure Cisco routers for OSPF in a wide 
variety of situations. 
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9.2. Web Site References 

The list below consists of pointers to web sites that provide useful information about 
routers, network security, and vulnerabilities. 

CERT 

http://WWW.cert.org/ 

The Carnegie -Mellon University Computer Emergency Response Team 
(CERT) maintains a web site about network vulnerabilities. Many of the 
incident reports, advisories, and tips are relevant to router security. 

Cisco Documentation 

http://WWW.cisco.com/univered/home/home.htm 

This is the root of the Cisco documentation tree. Erom this page, you can 
find lOS software documentation, tutorials, case studies, and more. 

Cisco Press 

http://WWW.ciscopress.com/ 

At the web site of Cisco’s publishing arm, you can order a wide variety of 
books about Cisco routers and related networking technologies. 

Cisco Security Technical Tips 

http://WWW.cisco.com/warp/public/707/ 

This page is the root of Cisco’s security area. Erom here, you can find the 
Cisco security advisories, information about security technologies and more. 


IETF 

http://WWW.ietf.org 

http://WWW.rfc-editor.org/ 

The IETF is the standards body that defines and maintains the protocol 
standards for the Internet. Use these sites to look up protocol standards and 
track emerging technologies that are becoming standards. 

Microsoft 

http://WWW.microsoft.com 

http://support.microsoft.com/support/ 

Microsoft’s site offers extensive information about networking their 
products, and about product vulnerabilities. This information can often be 
helpful in configuring routers that protect Microsoft-based networks. 
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Packet Storm 

http://packetstorm.securify.com/ 

This site is an excellent resource for network security news, vulnerability 
announcements, and tools. 

Protocols.com 

http://WWW.protocols.com/ 

This commercial web site offers descriptions and links to information about a 
very wide range of protocols and telecommunication data formats, as well as 
a pretty good glossary. 

Security Focus 

http://www.securityfocus.com/ 

Security Focus is a good site for security news and vulnerabilities. Although 
it doesn’t usually have much information about routers, it sometimes gives 
advice on how to forestall certain attacks by using your routers. 
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9.3. Tool References 

The list below describes some well-respected non-commercial tools that may be 
helpful in router adminstration and improving network security. 

Nmap 

http://WWW.insecure.org/nmap/ 

http://WWW.eeye.com/html/Databases/Software/nmapnt.html 

This is the most widely used port-scanning tool for Linux and Unix systems. 
A version is also available for Windows NT. 

TeraTerm Pro 

http://hp.vector.co.jp/authors/VAO02416/teraterm.html 

TeraTerm is a wonderful terminal emulator and telnet application for 
Windows operating systems. It makes a most effective Cisco router console 
application. 

Minicom 

http://WWW.pp.clinet.fi/~walher/minicom.html 

Minicom is a small, effective terminal emulation tool for Linux and Unix. 
While it has no fancy GUI, minicom is fast, efficient, flexible, and will serve 
well as a Cisco router console application on Linux. 

SATAN 

http://WWW.fish.com/~zen/satan/satan.html 

The Security Administrator’s Tool for Analyzing Networks (SATAN) is 
primarily oriented toward network security assessment of traditional host 
computers, but it can also identify security vulnerabilities of routers and the 
network boundary protection they provide. 


SAINT 

http://WWW.wwdsi.com/saint/index.html 

The Security Administrator’s Integrated Network Tool (SAINT) is an 
advanced derivative of SATAN. It can provide valuable security scanning 
services for hosts, routers, and networks. 

Ethereal 

http://ethereal.zing.org/ 

Ethereal is a very effective network traffic capture and analysis tool. Tools 
like Ethereal are valuable for diagnosing and testing router and network 
security. 
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UCD-SNMP 

http://ucd-snmp.ucdavis.edu/ 

UCD-SNMP is a free software toolkit for SNMP, created and distributed by 
the University of California at Davis. 


Nessus 

http://WWW.nessus.org/ 

The Nessus security scanner is a handy tool for getting a quick idea of the 
security vulnerabilities present on a network. While Nessus is primarily 
oriented toward scanning host computers, it may also be used to scan routers. 
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